I am getting a 404 error on this on this get:
http://localhost:9000/jspm_packages/github/Dogfalo/materialize#0.96.1.js
I have used jspm to install materialize, and it the package is there as expected.
However, there is no actual file named materialize#0.96.1.js in the Dogfalo directory.
Is there something else I should be doing to get this to work?
Turn out that the structure of the materialize#0.96.1 is not fully consistent and indeed missing materialize#0.96.1.js file in the package base folder. Possible solution is to use next minor version materialize#0.97.0 which has proper structure.
To get newer version run
jspm install materialize=github:Dogfalo/materialize#0.97.0
Related
I'm trying to use the new Blazor Javascript isolation feature. I'm importing my own JS file as per the example ExampleJsInterop.cs. It works until I try to import an NPM module from within my script. In my package.json I have set up a dependency on interactjs, and in my script I have added import interact from 'interactjs'; at the top.
I'm getting a Failed to resolve module specifier "interactjs" error. I'm not sure how to get past that.
Previously I was using Webpack to bundle my script and dependencies together into a single file that is added into my index.html as a tag. This was working fine, but I'm not sure how to continue using NPM packages with JS isolation.
Thanks!
A bit late, but I've just finished solving a similar issue.
The npm files are installed to the hidden node_modules folder. This isn't available to your script when you are running your app, unless you do something to make it available. however, even if you copied the interactjs file into your scripts folder it would still not work if it was an npm file. Those are meant to run in nodejs not a browser. So you would still need to use your bundler. I tried webpack, but had some issues with certain files so ended up with snowpack instead. I just finished a bunch of articles on javascript interop - part 4 deals with npm
I forgot that I left this question open for almost a year!
I ended up solving it using Snowpack to bundle the NPM package into the Blazor wwwroot folder. Credit goes to this article for pointing me in the right direction: https://nbarraud.github.io/js-in-blazor.html
The node-addon-api package is installed and I have been compiling using those header files just fine. But I went to take advantage of a feature and my addon would not compile; the symbol was missing from the headers. After comparing to the header file in their github repository, it was clear that what's installed is not what's current.
The file dates of everything (on a Windows install) is shown as 26-Oct-1985, but I don't know if that's npm just not getting the date right when it writes the file out, or what.
What do I need to do to get the current version in place? npm reports that v.3.0.2 is installed, but even after deleting the directory and letting npm fetch it again, the files are out-of-date.
This was strange; I finally realized that the reason the file kept looking like it was out of date was because the text editor I had it loaded in was not reloading when the file got rewritten by npm -- probably because of the file's datestamp never changing from 26-Oct-85. I discovered this after taking a diff between the installed file and the one in a clone of the package's repo: no difference.
I am using VS 2019 for Core 3.1 development and I installed Font Awesome whith Yarn:
yarn add #fortawesome/fontawesome-free
However, whenI try to reference it in my HEAD section like this:
<script defer src="~/lib/#fortawesome/fontawesome-free/js/all.js"></script>
I get the following error:
the 'fortawesome' doesnt exist in actual context
Package managers like yarn, npm, etc. just add the packages to your project. They generally aren't ready to deploy directly at that point, but rather require a build pipeline to create the actual JS/CSS resources. The #fortawesome/fontawesome repo is an exception in that 1) it's not actually a package and 2) the files are already "built". Even then, though, they still won't be in the right location.
I'm not overly familiar with yarn, but npm, for example, puts everything in a node_modules directory. That directory is not served by default, and should not be served, because it contains "raw" stuff. You'd need a separate build pipeline (using npm scripts, webpack, gulp, etc.) to build/copy assets into a directory that is served (i.e. wwwroot). That is likely the piece you are missing.
For this, since there's no build actually required, you just need to have the assets copied to something like wwwroot/lib and then you'll be able to reference it via the script tag on the page. That can be done with any tool like npm, webpack, gulp, grunt, etc. so you'll just have to research and pick the one that fits your needs best.
Total Linux noob here. I am trying to configure a Pleroma development environment on DO droplet. Installed LEMP, installed SSL, installed PostgreSQL, installed Pleroma, so far so good.
Then I installed Node, NPM, cloned Pleroma-FE (apparently it installs in /user/pleroma-fe folder). I am following the very brief build instructions here:
https://git.pleroma.social/pleroma/pleroma-fe
When I get to the command in those build instructions: npm run build
I am getting error: Error: Cannot find module '/user/build/build.js'
It's because actual path to the build file is /user/pleroma-fe/build/build.js
Apologies if this is a duplicate. I see other questions about this.
Fixing npm path in Windows 8 and 10
and the reply seems to set the PATH. This answer might apply to my situation. But my question is: it is clearly already looking in a well defined path (which is different from all the other questions, which don't seem to have well defined path in the error message). But it is the wrong path. How do I make it look in the correct path?
I tried the npm command and specified the complete path, and every variation. and none worked. So it seems fixing the path won't fix this problem.
Sorry I do not currently know enough Linux to be able to fix this. I tried to tag this with Pleroma but I don't have enough reputation to create a new tag. Any help is much appreciated. Thanks in advance.
I continued to work on this with some help of a Linux admin on Fiverr and the Pleroma developers chat with success, thanks to all.
The solution did not involve changing the path. There were several different things going on. First, I needed to change directory into the development project source folder:
cd pleroma-fe
Once I did that, npm found the build module. Next issue was Node was very old and I needed to get the latest version. I used the instruction here for NodeJS (10):
https://nodejs.org/en/download/package-manager/#debian-and-ubuntu-based-linux-distributions
Next issue was npm was missing some modules. This was fixed with:
npm install
After that the build completed with no errors.
npm run build
After a successful build, you will see a list of files that have changed as a result of the build.
Next issue is that simple changes in HTML text were not live, ie. not reflected in the refreshed web page. This is fixed by copying all the resulting build files to the production folder using rsync. In my case the command was:
rsync -av /user/pleroma-fe/dist/ /home/pleroma/pleroma/priv/static/
Pleroma is a neat Twitter-like user interface to ActivityPub fediverse, it includes a Mastodon UI as well, and thanks to the developers for making it free and open source.
I want to download a specific version of yarn by using the npm api
How can I achieve this?
After looking through the NPM Registry API, it looks like it would be pretty simple to do that.
GET: https://registry.npmjs.org/<package> returns a JSON object with a versions field and for each version there is a dist field which has a URL to that package's tarball.
If you know the version ahead of time, GET: https://registry.npmjs.org/<package>/<version> would also work.
If you just want the tarball straight up, the format for the URL for getting a package's tarball is https://registry.npmjs.org/<name>/-/<name>-<version>.tgz. Although the registry documentation says that this might not always be true.