Ember CLI applications have a package.json that lists everything as a dev dependency. Even stuff that is needed in the app's production version. For instance packages like ember and ember-data are installed as devdependencies.
As a reference, here's a sample of what I'm talking about: https://github.com/ember-cli/ember-new-output/blob/master/package.json#L17-L38
What's the reason for this?
In the context of application:
As #Lux mentioned in the comments, you don't need them after the build.
The output of the application is the build, that is supposed to be the final product. Further, you generally don't depend on another application. You generally depend on a package or an addon.
In the context of addons:
I think there is an opinion to display all of the addon dependencies of an application at the application's package.json file. By doing this way, you can prevent that an addon unintentially adds a js file to the build.
As a result, the ember way of managing dependencies is to leave all of your dependencies at your devDependencies and add all of the dependencies of the addon to the application's package.json with default blueprints. So the end user can tune them.
Related
I am trying to breakout a couple of Vue.js components from a primary application into an npm package stored on a repository. This package can then be imported and used across two separate sites. I am using Webpack to bundle everything but have had a few queries about the layout that should be used.
Seeing that things like Vue.js and Vuex will installed as dependencies on the main application, I know that the package will have access to these once installed on the two main applications.
My primary confusion is how do I deal with dependencies that belong to the package only, do I bundle this as part of the webpack and will running npm install on the applications automatically install the 'dependencies dependencies' if you will? Is there a general standard for these things?
The simplest thing to do is list them in your dependencies section in package.json. The package manager tool you're using (usually either npm or 'yarn`) will take responsibility for deduping the dependences, so if your parent app and your subproject both have the same dependencies, you'll only end up with one copy in the final bundle.
I would strongly suggest that you be looser on version numbers in the component projects then you are in the parent project. So in the parent maybe you say the dependency is "vue": "1.2.3" and in the component project it's "vue": "^1.1.0" or something along those lines. This way the parent can control the specific versions and your component picks up the actual version from the parent.
I have an Angular 6 library which contains couple of modules with its routes. This library also works as a standalone application.
I have used ng-packagr to pack and publish the library. When packing all the dependencies included in package.json dependencies also gets shipped and is installed when consumed by an application.
This behaviour results in duplication of angular core libraries and app does not start.
One of ways i have handled is include all the dependencies as devDependencies in package.json, so they wont get shipped. Is there any better way to handle this without moving to dev dependencies ?
It looks like having dependencies as devDependencies is the solution for now, as having just peer dependencies works when inported as a library but it doesn't install deps when using in an application.
As per the official website, the correct way to save electron files is:
npm install electron --save-dev
Electron is actually required for running the app (quite literally: require()) and this goes against the top voted answer here. So why do we make this exception, if this is even one?
The fact that you require a package is irrelevant to whether it should be considered a dependency or a devDependency (in the npm sense). E.g. many projects use webpack API (i.e. const webpack = require('webpack')) but list it as a devDependency.
The reason is also explained in the post you link to: when you publish your package, if the consumer project needs other packages to use yours, then these must be listed as dependencies.
If your package uses some modules only for build, test, or bundles them into a dist file (i.e. what will be used by the consumer project), then those modules should not be mentioned in dependencies. We still list them in devDependencies for development.
Now in the case of an electron app, there is little chance you will consume your app as a node module of a consumer project, therefore the above convention is not really relevant.
Furthermore, we fall in the case where the electron package is bundled as part of the built output. There is no need for your user to get electron from npm to use your built app. Therefore it matches well the definition of a devDependency.
That being said, IIRC some electron packagers bundle your dependencies into the built app, so you still need some rigour in filling this list.
Cause those binary won't being used when you actually packaging into installer. Most of installer / packager for electron will build package with electron binaries, instead of using dependencies.
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.
If I have a directive, and I wish to package it in its own node package; and then include it from another another node package containing the main angularjs app, how would I do this?
My rough idea about how to go about this is:
put the html, javascript, and css for the directive in the package folder
enable compilation of these assets - preprocessing, minification (how?)
configure as bower package
in the app folder install the bower package
how to do this locally, without publishing?
in the angular.module() statement that creates the main app, add the name of the module containing the directive
Is this correct?
Have I missed out on anything?
Your idea of how to go about this looks good to me. To answer your questions in the list:
Look at Grunt or Gulp for your preprocessing / minification needs. These are both excellent build tools. Grunt is more widely used, but Gulp is newer and gaining a lot of ground. I'd look at both and use the one that suits you.
How to use a local bower dependency w/o publishing:
In your main app's bower.json file, instead of putting a version number for your module, put the folder where it can be found on your local system, like so:
{
"dependencies": {
"my-module": "/home/me/modules/my-module"
}
}
To clarify, you refer to it as a "node package" in your question, but in reality, you are creating a Bower package. Node packages (published to npmjs.org) are for node, and unless processed with something like Browserify, won't run in the browser (and even then, the node package can't do anything the browser doesn't support, like file access.) Bower packages (published on bower.io) are specifically for the browser. You will however find packages that publish to both NPM & Bower, such as jQuery or underscore, but you can't use the npm jquery package in the browser, it's built to run in node, and vice-a-versa.