I am behind a corporate proxy, so my build can't download the node-sass-binaries directly from github. For now I have a Nexus3 raw repository (hosted). The biniary files are downloaded from https://github.com/sass/node-sass/releases/download/{version}/{artifact} and I upload them manually to the repository. In the .npmrc I reference my repository with node-sass-binary={path to repo} and it works fine. But I don't want to manually download and upload the files every time a new one is needed.
Now I want to set up a proxy repository that gets the artifacts automatically (like it is working with maven central).
What have I tried? I have created an Raw (proxy) repo and entered the download URL https://github.com/sass/node-sass/releases/download/
But this isn't working.
The error I get:
node-sass#4.11.0 install C:\Project\ng\src\node_modules\node-sass
node scripts/install.js
Downloading binary from https://myserver/nexus/repository/node-sass-binary//v4.11.0/win32-x64-72_binding.node
Cannot download "https://myserver/nexus/repository/node-sass-binary//v4.11.0/win32-x64-72_binding.node":
HTTP error 404 Not Found
Hint: If github.com is not accessible in your location
try setting a proxy via HTTP_PROXY, e.g.
export HTTP_PROXY=http://example.com:1234
or configure npm proxy via
npm config set proxy http://example.com:8080
node-sass#4.11.0 postinstall C:\Project\ng\src\node_modules\node-sass
node scripts/build.js
In my opinion this error message makes sense because if I call https://github.com/sass/node-sass/releases/download/ directly in the browser I get a 404 message.
So am I using the wrong URL or do I miss something else? Is it even possible to do this? Thanks for your help.
I had a similar problem.
I believe you are using Node v12 which is not supported with node-sass#4.11.0
https://github.com/sass/node-sass/releases/tag/v4.11.0
and for this reason win32-x64-72_binding.node is not found (72 refers to Node v.12 ...)
So, use node-sass 4.12.0 or higher in order to fix this issue.
Related
I've been experimenting with single-spa for a while, and understand the basics of the developer experience. Create a parcel, yarn start on a unique port, add the reference to the import map declaration, and so on. The challenge with this is that as my root-config accrues more and more modules managing ports and import-maps starts to get tedious. What I want is to publish these modules to a central repository and load them from there (e.g., http://someserver.com/repository/moduleA/myorg-modulea.js, etc.).
I was recently introduced to localstack and started thinking maybe a local S3 bucket would serve for this. I have a configuration where builds (yarn build) are automatically published to an s3 bucket running on localstack. But when I try to load the root config index.html from the bucket I get the following JS error:
Unable to resolve bare specifier '#myorg/root-config'
I can access the JS files for each parcel and the root-config just fine via curl, so I suppose this would be a problem with any http server used in the same way. I can flip the root config to use the standard webpack-dev-server instead (on port 9000) and it works okay. So I'm guessing there's a difference between how a production build resolves these modules vs. the local build.
Has anyone tried something like this and got it working?
I had a similar issue that I got to work with http-server by adding each child .js file to a sub-folder in the root-config directory and launching the web server at the root-config directory level.
"imports": {
"#myorg/root-config": "http://someserver.com/root-config.js",
"#myorg/moduleA": "http://someserver.com/modules/moduleA/myorg-modulea.js",
"#myorg/moduleB": "http://someserver.com/modules/moduleB/myorg-moduleb.js",
"#myorg/moduleC": "http://someserver.com/modules/moduleC/myorg-modulec.js",
}
Note: By default, Single-SPA has an "isLocal" check before the current import mappings. You'll need to remove this if using a production build or it won't load the correct mappings.
<% if (isLocal) { %>
In my case, I was using localhost instead of someserver so I could navigate into the 'repository' folder and run npx http-server to get everything to run correctly.
I was hung up on this for a little while so hopefully this leads you in the right direction.
For the record, after trying several approaches to hosting a repository as described above, I found the unresolved bare specifier problem went away. So I have to chalk that up as just not having the right URL in the import map. Measure twice, cut once.
I have a serious problem. I tried to install ionic, cordova, angular, react-native-cli, https-status-error and other packages and it always returns:
npm ERR! code E418
npm ERR! 418 I'm a teapot: ionic # latest
Please note that it may be wrong and I do not understand what is happening. It was fine until 3 days ago.
So, post may 29th '18, this is the common error being faced worldwide by devs working behind corporate proxies. The following tweak fixed the issue for me:
Go to your .npmrc file.
you'll have the following similar content in the file depending upon the configs you are setting up-
strict-ssl=false
registry=http://registry.npmjs.org/
python=C:/Python27/python.exe
msvs_version=2015
http-proxy=<WHATEVER-PROXY-YOU-USUALLY-ADD>:8000
Note: Ignore the extra configs like python variable path.
Update the registry link to 'https://registry.npmjs.org/'. So your file would look like this now-
strict-ssl=false
registry=https://registry.npmjs.org/
python=C:/Python27/python.exe
msvs_version=2015
http-proxy=<WHATEVER-PROXY-YOU-USUALLY-ADD>:8000
And Viola! you are all set to fire your npm install commands :)
Work for me!
If you set proxy should be unset.
npm config delete proxy
npm config delete https-proxy
Solution resolve npm ^___^
npm cache clean --force
npm cache verify
I had the very same issue and managed to fix it.
In my case, I initially had the value of "http://registry.npmjs.org/" and changed it to "https". Below are the set of commands I ran:
npm config set registry https://registry.npmjs.org/
npm cache clean --force
npm cache verify
npm install
we have to add proxy information in .npmrc file with userid and password. You will not find any issues. Recently people are getting http 418 - tea pot issues. That we can fix setting up registry with https like below
USE THIS:
proxy=http://<>:<>#<>:8080/
https-proxy=http://<>:<>#<>:8080/
registry=https://registry.npmjs.org
Are you behind a coorporate proxy? I was facing the same error when I tried to run npm install. What I did was to remove the proxy configuration from NPM, like so:
npm config rm proxy
npm config rm https-proxy
That did the trick.
418 I’m a teapot: This code was defined in 1998 as one of the traditional IETF April Fools’ jokes, in RFC 2324, Hyper Text Coffee Pot Control Protocol, and is not expected to be implemented by actual HTTP servers.
However, we know at least one implementation does exist now.
It's a bug or weird joke.
As #TomLingham suggested, follow https://github.com/npm/npm/issues/20791 to watch progress resolving the issue and for some workarounds.
For example yarn still healthy.
After visiting many sites and testing everything i found,
This Solution finally worked for me. If you are using Windows,
Click windows button and type "run"
Type .npmrc and open this file using your favorite editor.
Replace "registry=http://registry.npmjs.org/" with "registry=https://registry.npmjs.org/" and save.
Note: If you have any proxy issues too..you can set your proxy like below in the same file. In my case i have a special symbol "#" in my password.
When i tried changing proxy using npm config set proxy command these special characters got converted to something else :) So you could eliminate all these headaches if you set your proxy along in this file directly.
Your final .npmrc should look like below. you could remove proxy lines if you do not have any issues with proxy and do not forget to replace the port in below example with your proxy port.
registry=https://registry.npmjs.org/
proxy=http://username:password#yourproxy.net:8080/
https-proxy=http://username:password#yourproxy.net:8080/
strict-ssl=false
I too ran into the same problem today, It looks like we all are in the same boat.
https://github.com/npm/npm/issues/20791. Some solutions are provided in the link. You might want to look into it if it is a pressing issue.
I'm attempting to set up my TeamCity instance as a private NuGet package feed. I have successfully configured the feed and set up a build that publishes artifacts.
However, I'm running into a problem when attempting to install a package in my source code from the TeamCity feed:
By going to the "NuGet Feed" page in TeamCity, I can see that the feed URL is
http://localhost:8080/httpAuth/app/nuget/v1/FeedService.svc/.
I have set my local Visual Studio (running on my local machine, not the TeamCity server) as
http://[my-TC-server]/httpAuth/app/nuget/v1/FeedService.svc/, and I can view the package in the NuGet manager with the expected attributes.
However, when I try to install the package, it fails because the src attribute in the package configuration is still set to http://localhost:8080/httpAuth/app/nuget/v1/FeedService.svc/download/NuGet_[myPackage]/73:id/p[myPackage].nupkg (I can see this by viewing my TeamCity-hosted packages at http://[my-TC-server]/httpAuth/app/nuget/v1/FeedService.svc/Packages()), and the install fails because it is looking on my machine for the package file, and not on the TeamCity server. I assume the src attribute is set at pack time and grabbed from the TeamCity configuration somewhere.
If I navigate to to
http://[my-TC-server]/httpAuth/app/nuget/v1/FeedService.svc/download/NuGet_[myPackage]/73:id/p[myPackage].nupkg
in a browser, I can successfully download the package.
Is it possible to configure the feed URL in TeamCity to be http://[my-TC-server]/httpAuth/app/nuget/v1/FeedService.svc/ so that the src param will also use [my-TC-server] instead of localhost? I can't find an option in TC to do this, and I haven't found any documentation for dealing with this problem.
If it is not possible to configure the feed URL, what would a good solution be so that my local machine can download the package from my TeamCity server?
It was two things:
I needed to configure my TeamCity Server URL (Administration>General Settings)
I was running into this problem with my server's reverse proxy, and running this command on the server fixed the problem (the server was not preserving the Host header in requests)
After those two, everything's all good!
I am trying to deploy Powershell modules from my https pull server but couldn't. I don't know what I'm missing here. These are things which I already did or tried:
Setup a https based pull server using instructions outlined at https://msdn.microsoft.com/en-us/powershell/dsc/pullserver
Register a pull client using instructions mentioned here https://msdn.microsoft.com/en-us/powershell/dsc/pullclientconfignames
On my pull server I've placed modules under C:\Program Files\WindowsPowerShell\DscService\Modules as xWebAdministration_1.12.0.0.zip and xWebAdministration_1.12.0.0.zip.checksum
If I double click xWebAdministration_1.12.0.0.zip file it contains: DSCResources, Examples, Tests, HighQualityResourceKitPlan.md, README.md and xWebAdministration.psd1 at root level, Under DSCResources I have all MSFT_* folders and other stuff
When I run a custom configuration on my client node which requires xWebAdministration module, I get module not found exception.
I looked at client's event viewer for errors but don't see anything related.
Any help is appreciated.
Thanks!
Have you tried Publish-DSCModuleAndMof from xPSDesiredStateConfiguration?
You have to run Install-Module xPSDesiredStateConfiguration first.
You can find an example of using this here.
I'm following the instructions for installing Ardor3D as an Eclipse Project Set via Subclipse; instructions at:
http://www.ardor3d.com/wiki/svneclipsetutorial
I installed Subclipse from
http://subclipse.tigris.org/
and installed fine. If I go to Eclipse's Preferences and Team|SVN I can see that the SVN Interface Client is JavaHL, and hence installed fine.
However, when I come to checkout the code at:
http://ardorlabs.svn.cvsdude.com/Ardor3Dv1
by selecting New|Other|SVN|Check Projects from SVN I get the following error message:
RA layer request failed
svn: Unable to connect to a repository at URL 'http://ardorlabs.svn.cvsdude.com/Ardor3Dv1'
svn: OPTIONS of 'http://ardorlabs.svn.cvsdude.com/Ardor3Dv1': could not connect to server (http://ardorlabs.svn.cvsdude.com)
I know the URL is valid as I can install the above fine on my work m/c of WinXP. However, the same installation on my personal laptop of Win7 fails to connect.
I tried temporarily disabling the firewall and it still fails.
I've tried playing around with the config and server files in:
C:\Documents and Settings\Administrator\Application Data\Subversion
but to be honest not 100% sure as what to change, if anything as I'm not using proxy settings.
If there's an expert out there who's knows the solution to this problem I would greatly appreciate hearing from you.
Thanks
Graham
PS. I find the error message "RA layer request failed" confusing as the URL is valid.
I had exactly the same problem, which turned out to be caused by a proxy server. The solution to my problem was to configure subversion to work with the proxy server, however it was not obvious how to do this.
You should have a directory similar to : C:\Documents and Settings\UserName\Application Data\Subversion
In that directory there will be a file called servers.
I un-commented and edited the following entries and my subversion is now working fine with Eclipse:
http-proxy-host
http-proxy-port
http-proxy-username
http-proxy-password
Why exactly you can't configure this through Eclipse is abit of a mystery, but there you go.
Another user account could login, I got the error as described above. The difference was the Proxy setting which was missing in my account. It is stored per user in the Registry and I could easily change this in the Tortoise SVN config.
We encountered this error with our server. While we were able to successfully access the CollabNet 5 SVN admin console, navigating to the repository to browse it from the admin console would fail. We also were not able to connect from Subclipse clients.
The problem turned out we were not hitting the correct port on the server. We had reconfigured the default port from 80 to 4343 and the admin console reported the changed setting but the server was still running on 80.
For what it's worth, in order for the configuration change to stick, we had to bring the repo server down and make the change in the admin console and then restart the machine. We were then able to browse the repo from the link in the admin console.