I have a snowpack project that I started from the blank template. My index.js file calls a function from another module I'm developing that I have installed using npm link.
When I change a file in the other module, it doesn't get updated in snowpack. Even when I restart the dev server, it doesn't update. I have to restart snowpack with the --reload argument to clear the cache.
How do I make sure changes to files in node_modules get recognized by snowpack so that they are rebuilt?
Unfortunately the way Snowpack works is it caches the node_modules dependencies and rarely rebuilds them.
In the documentation section Using NPM Dependencies
Because your dependencies rarely change, Snowpack rarely needs to rebuild them.
Each build tool has its pros and cons, and Snowpack is not going to work for you, in this instance where you still need to update the linked dependency.
You might want to look at other build tools like Webpack. Here is stack overflow answer on correctly configure Webpack to watch only for the linked dependency.
It seems that even the Parcel 2 doesn't detect changes in linked dependencies.
You can delete .cache/snowpack inside node_modules folder for rebuilding. More concise you can delete specific folder which you want to make it rebuild, This is only hack I found that works.
Related
I just recently heard of the package.json file but all my small projects have always worked without it.
I've installed many npm modules globally and always use var x = require("express");"just for example" without even initializing the package.json and putting express as a dependency.
Is it really important
First of all, I strongly doubt require("express") will work out of the box without having the express package installed in your project's node_modules folder, but just globally. There are ways to accomplish this, though.
But even if you accomplished to require packages from the global installation folder, what happens if you have multiple packages requiring different versions of the same package? There may be breaking changes between major versions of packages. So if you install a new version of package xy globally, older projects of yours expecting a different version of package xy may stop working.
On just your local machine, you can achieve all that, still without a package.json though.
The main purpose of the package.json comes clear, when you want to share your project with other people. Aside from some basic information (like a package name and some description), it will also list the dependencies which need to be installed for the project to be runable. While the necessary dependencies may exist on your machine, how will you make sure, they are also installed on a different machine without having them listed somewhere? And the place for listing the dependencies of a package is -- surprise surprise --- the package.json file ...
They are global, not in your project so when you do the deploy, you will must have to install all global for each server.
Yuu can install packages-cli global, but project dependencies ( also dev on dev dependencies) is better have its own package.json so you can deploy.
Also if you share your project, how someone will know what packages is needed.
The better is to have for each project its own package.json on its root folder, even if you always use the same libs.
I am working on a VueJS web app. One of the modules it uses is a wrapper for a javascript library installed through npm and packaged to integrate into vuejs. It does not quite fit our needs, we need to add some functionality to it, so I want to fork it and edit it.
The repo has two folders: src and dist.
As far as I understand, src is the actual src code while dist is a minified version for distribution. Questions:
If I want to edit it, how do I deal with the contents of /dist ? Do I delete it?
Do components installed through npm use the /src/ version or the /dist/ one?
If I delete /dist, work on the /src code, how do I recreate /dist based on the modified /src files?
Thank you.
Based on your questions, I would suggest you get a bit more familiar into your stack and how to actually build your appication.
Generally speaking the /dist folder contains automatically generated files, which may be uploaded to a webserver of your choice. Since you are using VueJS, you should be able to generate these files by running npm run build.
If I want to edit it, how do I deal with the contents of /dist ? Do I delete it?
As I already mentioned, these files are automatically generated by running npm run build. Therefore everytime you run this command, everything in /dist, will be automatically updated.
Do components installed through npm use the /src/ version or the /dist/ one?
Your working directory is always /src. Dependencies can be used like in any other application (this example uses Axios, which is a http client):
import axios from 'axios';
const httpClient = axios.create({ baseURL: 'https://api.something.com' });
httpClient.get(/* ... */);
If you are a beginner and are not 100% sure about how to use depencencies, I highly encourage you to read this article: An Absolute Beginner's Guide to Using npm
If I delete /dist, work on the /src code, how do I recreate /dist based on the modified /src files?
You do not have to delete anything in /dist. Simply running npm run build automatically will add the latest changes.
Please keep in mind that running npm run build is only relevant for your production environment. For your development environment you always want to use a dev server, which can be started with npm run serve.
I am doing my first angular project and I have to upload it to a Development test server. Problem is that, an Angular project (event in default state) has so many files that it takes a lot of time to upload it.
I investigated and the .gitignore file seems only to be to avoid the commit of the files or folders specified there.
Could you please tell me if there is a way to minimize the number of needed files to upload and install or use them later, in local, in a safe way? Without risks of corrupting the project.
If you are using Angular CLI you can get a production build by doing
npm run -- ng build --prod
in the project directory. This will create a minified, bundled version of your app in the dist folder, ready for upload. You will then need an http-server running to serve these files.
As #yarz-tech suggested, the solution was to remove the node_modules each time I upload it. Then, when someone downloads it and wants to work with it again, must execute npm install. That allows npm to install all the dependencies our project needs, based on what is is specified on the package.json file, which appears not only for Angular projects, but for Node for example.
Thanks to everyone.
I would like to get an explanation about the way npm modules getting build on install, I'll give an example:
When I'm taking a look on the material-ui npm module sources on GitHub, There's sources but there's no built files, when I take a look on my project node_modules/material-ui directory I can see that the directory contain only the built files (es5, uglify).
I'm trying to understand how that magic happens? I see that there's build script inside the package.json but there's nothing that tell npm to run it on install, what am I missing?
Thanks
Usually modules don't get built on the client's machine, because that would take additional time and might fail because they are using an older version of Node.js that doesn't support the build tools, and of course the build tools would need to be installed as well, which would make the process even longer. Instead you build it before publishing. What is on GitHub is different from what is actually published to the npm registry. Most modules don't check in the built sources into GitHub (although some people prefer to).
Presumably material-ui does this process manually and just publishes the built sources, as seen in Unpkg - material-ui.
Some other packages like redux use a prepublish hook, which builds the necessary sources just before it gets published when running npm publish (Redux prepublish hook), which reflects the published package as you can see in Unpkg - Redux. It's pretty close to the original source on GitHub but only contains the relevant files, including built files that are in its .gitignore file. Because a lot of files are unnecessary to be published (e.g. the test directory, rollup.config.js etc.) and would only take up space on the client, you can specify files in package.json to only publish the listed files (Redux files).
You just happened to have picked a quite confusing package with material-ui when it comes to publishing, whereas redux is a lot easier to understand.
I am looking through the documentation and features for jQuery Globalize (https://github.com/jquery/globalize) and although it is a bit heavy and complex, it seems to do most of what I want.
The problem is maintenance.
As I understand it, to have access to each of the modules (messages, numbers, etc), I must first run the build in order to acquire a ./dist folder. So in my company's automated build system (largely ant-driven), the following steps would be required:
Ensure Node installed
Ensure Grunt and Bower installed
Run both npm install and bower install
Modify the grunt task to exclude the failing "commit" task (why do they even want an automatic commit on build?)
Run the whole grunt to get a ./dist folder
Execute my project grunt file, which copies the files out of this dist and further processes them
This is rather heavy when all we really need are the files ultimately found in dist. The bigger problem is that an update of the plugin then requires downloading the repo again and running through the same process and hope that dependency fetching and grunt build execution tasks don't fail.
Does anyone familiar with globalize know a better way to do this that's more future-proof? Any idea why the dist files arent' just part of the repository?
As mentioned directly in the README.md file, you need to go to a "tagged branch". This means going to the "releases" tab of the repository and picking an appropriate release. This will download a versioned release which includes the dist folder.
Clicking the "download" button in the sidebar will only retrieve the master development branch, which is not tagged and does not include dist.
As of this writing, the tagged branches found on the "releases" tab are at this link: https://github.com/jquery/globalize/releases