How to tell if a package is part of deployment - javascript

I have a react application. I'm using react-scripts build. As I understand (from this link), the package-lock.json doesn't affect the build and the build will take any packages it needs that are imported in the files (regardless if they are dev dependencies or not). How can I check if a certain package was installed on a deployed environment? The reason why I'm asking is that we want to verify that no dev dependencies or any of it sub dependencies are part of deployment to customers.

Related

Will electron-builder use dependencies that it doesn't need

I have been wondering this for a while and i haven't found a specific answer.
I am building a whole app using Electron and React to make the ui.
My question is if i should have a 2 complete different source code for each part of the app (electron and react) because i don't know very wekk how the package electron-builder works.
To be precise, since i have installed react (and react packages related) and some others that i just use for the ui part, when i build the app for distribution, will electron include the dependencies that doesn't require? Making the final bundle bigger!
While electron-builder has configuration options to specify which files are to be included, it is not a replacement for a tool like webpack.
electron-builder creates the installer/target artefact for your platform and packs the files you have specified.
It does not sift through your node_modules via tree shaking to create a minified script that only contains the code you need.
You can compare it a with the files array in the package.json that tells npm pack which files should be put into the tarball.
In the default configuration (and I don't know if you can overwrite that, but it is surely worth a try by setting specific node modules to ignore) it will include the entire production dependencies.
Another solution than manually ignoring the react dependencies would be to hold your react app in its own directory in your project and only include the build artefact.
gui/
|_build/
|_your built stuff
|_your react stuff
|_node_modules
|_package.json
main.js
node_modules
package.json
In this case you would configure electron-builder to include main.js and gui/build. With this electron-builder should only include the production dependencies of the outer project.

Installing an NPM module without installing its dependencies

We have a project that uses NPM as its package manager. We use Webpack to build a Javascript app that is consumed by a Rails app. The app is fully self-contained and is built to a /dist directory that is included in the package. For reasons that are out of scope of this question, the Rails app consumes this App as a UMD module, loading it via a script tag and initialising it:
App({})
The problem is that the package has a large number of dependencies. When the Rails app installs the package, it also installs all the package's dependencies, despite the fact that it doesn't need or use any of these dependencies because everything it needs is present in the App bundle.
Is there any way the Rails app can install the package (and access the app in the /dist directory) without also installing all the package's dependencies?
Note that we don't want to move all dependencies to the app's devDependencies as that will be confusing (and we may well end up with multiple ways of distributing the app, including via es6 import). Also note that we are using Yarn as our package manager.
To clarify, we are using NPM as a means of sharing versioned releases with the Rails app, however the only thing in the package the Rails app cares about is the UMD module. It is very useful for the Rails app to be able to do yarn add Example#latest and immediately pull in the latest version of our App, however it doesn't need to resolve the package or its dependencies as they are already baked into the UMD module.

Is npm install --save ever used with webpack?

I am learning to use webpack and generally getting in to the Javascript world, including npm.
Several answers deal with --save vs --save-dev when using npm install. My understanding is that their use (and updates to package.json) is actually useful when recreating either a run or a dev environment via npm install <the package being developed or ran>
--save is used to save packages needed to run the app in node.js, that is on a server
--save-dev is used to save packages needed to develop the app
a bare npm install <module> just installs the package, without enabling the possibility to install it somewhere else though the appropriate entry in package.json
Therefore, in a webpack context, is --save ever used? I belive not, because what is created is a JS bundle which is then included in the HTML file, and ran in a browser. In that sense, there is never a need to "save modules needed to run your app".
In the same vein, --save-dev is useful (again, in a webpack context) at it allows someone to develop elsewhere (in that case both modules in the app (say, moment.js) and logistical ones (say, gulp) should be installed with --save-dev, right?)
Finally, a bare npm install <module> is also possible (although less useful) is the development is not intended to be done elsewhere (the modules are still installed but no mention of this fact is made in package.json).
Is this correct? Specifically, is the assumption of a lack of --save in a webpack context true?
Anything that it utilised in the production build of your application should be listed in save. For example if you use React, your application utilises React in the final production build. It doesn't matter that your file is bundled but the fact that it's heavily relied upon running when compiled.
Anything that is used during development should be listed under devDependency. In this example, once WebPack has finished bundling your files, we no longer care about WebPack because it's not apart of the final compiled file.
--save-dev : Anything that is used during development such as Unit testing frameworks or bundlers etc.
--save : Anything that is used within your application such as Axios, React, Vue or Chart.JS etc.

Frictionless development of multiple SystemJS/JSPM packages

I'm working on a set of JavaScript projects and some of these have dependencies between them. I've chosen JSPM as my package manager - which is all fine. But during development I want to have the most efficient frictionless way of working with this.
What is the best way for me to be able to have a dependency from one project to another in a totally transparent way - when I work on it locally, I get to just jump between projects without having to do any packaging or installation of packages and at the same time package information with its dependencies being what is expected to be for release (public package) and builds on the CI??
With NPM I could be doing npm link- anything similar I can be doing??
You could use jspm link
Running jspm link in a module will publish it into the locally global "link" repository.
Running jspm install --link will then install a project from the "link" repository.
The only functional difference between npm link is that (for the moment at least) jspm link will need to be run every time your local code changes. This can be automated with a watch task (see jspm-cli#481).

Using stellar-lib api with Meteor

this is probably a silly question but am new to Meteor and struggling a bit. I want to build a stellar app that tweets when you get stellar. There is a nice Javascript API stellar-lib that works on node, but im unsure how to access the modules in Meteor...
I'm also building an app with Meteor and stellar-lib and have found two options:
1) You can manually copy over the built stellar-lib.js or stellar-lib-min.js from the build/ directory from either the github repo or the node_modules folder you installed it to when you ran the npm install command.
If you do this, you will have to copy the .js file to client/compatibility, otherwise stellar-lib will not work (note: this means you can only use Stellar on the client).
2) If you need it on the server, you can also have browserify wrap stellar-lib for you, then copy the output to lib/ in your Meteor app's root directory. I did this in my repo here with gulp.
Here's a short explanation to how 2) works:
.gulp is where I'll install my NPM modules where they will be ignored by the Meteor build environment (because the folder is hidden).
In deps.js, I require the modules I would want to use in my Meteor app as I would if I was using them in a traditional node.js app. package.json defines the modules I'll install with NPM and the gulpfile.js describes a build task that will resolve my require statements and output a single deps.js file that includes my dependencies to my Meteor app's lib/ folder.

Categories

Resources