I use npm scripts a lot for my javascript/node projects (npm start, npm test, and npm run build and others), and I was wondering if there is something similar for elm-packages, or if we should use npm scripts instead, and if I have to do it, why do we need a package.json and a elm-package.json?
The quick answer is that (as of May 2017) there's not support for this in elm-package.json.
As for the future: Evan Czaplicki has said on elm-dev mailing list that the file format and functionality will get revamped a little bit (probably with the 0.19 release), but most probably mainly with regards to application vs. library distinction. Based on that, I don't think elm-package.json will get this functionality anytime soon.
I think most devs have some node stuff running to handle their dev environment (e.g. webpack stuff) so you will always have package.json available for such scripts anyway.
There is a question about whether elm should embed its dependencies within package.json but, while most dev instances would have package.json, anyone just trying out with elm-reactor would not. So I think the present situation is here to stay, and enables you to do what you want.
Related
I've recently installed some npm package (recommended Kubernetes client) for my react app.
After writing code that uses the package and deploying the code for testing I got some weird errors about missing functions or packages. Then I've read the documentation and realized that the package was Node-only.
Is there any way to check that the npm package works in browser before writing code that uses the package?
Python packages specify compatible python versions. Do npm packages have something like this whether they indicate support for particular Node versions and the browsers?
Some packages/libraries contain .browserlistrc file which I've found to be a starting point to find out the browsers and platforms the devs intend to support or have their code compile for. While it may not always be true and the package might just be able to support a browser that isn't mentioned, it's a good starting point. It surely helps to find out if IE (the bane of front-end dev) is supported or not.
Then again many packages don't necessarily include a .browserlistrc. You can then check the package.json for a "browserslist" field.
If neither are found, you can always clone the repo and add your own .browserlistrc in the root with queries that will let you know if the package supports your intended browser or platform - little more work but yeah it can help. Not full proof but a decent enough way to find out.
Though the best answer is really to just ask the maintainers.
As title indicates, I'm working on a project where different members have used different tools (NPM and Yarn) for handling packages and modules etc.
We aim to transition to use ONLY Yarn (not our decision). Would anyone be able to share resources detailing how to accomplish such a thing? Or help quickly walk me through the steps?
I tried googling for answers but every single result is yet another article explaining why you should ditch NPM/Yarn and move your project to Yarn/NPM, without explaining the steps one would need to take to move from using both to just one mid-project. Thanks!
It looks like Yarn has a page talking about how to migrate to it from NPM:
https://yarnpkg.com/lang/en/docs/migrating-from-npm/
In most cases, running yarn or yarn add for the first time will just work. In some cases, the information in a package.json file is not explicit enough to eliminate dependencies, and the deterministic way that Yarn chooses dependencies will run into dependency conflicts. This is especially likely to happen in larger projects where sometimes npm install does not work and developers are frequently removing node_modules and rebuilding from scratch. If this happens, try using npm to make the versions of dependencies more explicit, before converting to Yarn.
As of Yarn 1.7.0, you can import your package-lock.json state, generated by npm to Yarn, by using yarn import.
They use many of the same files and structures. The important thing is to check-in the yarn.lock file and make sure everyone is installing using Yarn instead of NPM.
If you have a build server, you could probably use it to enforce those dependencies, but it would be more work.
Recently, node package manager is very popular and doing a lot of job for us, however it is really difficult to understand what is going on under the hood. I really like simple tags to insert Vue, Babel etc. Haven't worked on big projects, I really wonder is there any disadvantages using script tags over npm-cli.
When you npm install a library, plugin, extension, etc it can be declared as a dependency with a --save flag. In doing so it is marked as a dependency in your package.json file, which is key to version control for your dependencies. If you just use the CDN you are pulling in a path to a library that may be deprecated at some point in the future.
During development it is ok to use CDNs, but in production it is not good practice for dependencies (though I do it for certain exceptions, such as a google font).
I should clarify that I'm not that experienced with front-end tools, so I'm sorry in advance if I'm asking something obvious and stupid.
So far I've been using bower for front-end and npm for server-side, although each of the tools mentioned has its advantages and by that I mean flat dependency management of bower (reduces load from the client) and nested dependency management of npm (helps with versioning), it has become quite cumbersome to use so many tools (webpack, browserify, etc.). I may've been using these tools the wrong way and could've used either of them with some option (not known to me) and have been only scratching the surface, I just took this answer as my rule of thumb and have been doing so ever since I've read it. It would be great if I could reduce at least these two to one.
Lately I've become curious about yarn and with all the hype around it, it seems as if it has been doing a good job and as if it will replace npm completely. As I've read the docs I've discovered the --flat option and that made me wonder if it would be possible to use it as bower replacement as well? If so, does it mean I could have either flat or nested dependency manager (by just having multiple JSON files for back- and front-end)?
I would really appreciate if someone could point me in the right direction!
It depends on your exact use case, but... probably.
Currently, the major trend seems to be towards module bundlers such as Webpack and Browserify (and hence either npm or Yarn) and away from Bower. You can read an excellent overview of the situation at NPM vs. Bower vs. Browserify vs. Gulp vs. Grunt vs. Webpack, along with some reasons why you might want Webpack instead of Bower.
At the minute, you're probably using HTTP, where it works out faster to have one JavaScript bundle file rather than lots of source files (as would occur with Bower). That's why Webpack and Browserify are so popular (among other reasons) — they should increase performance and simplify development a lot.
Side note: HTTP/2 will diminish the value of module bundling, because multiple requests will become far less costly. See What is the value of using Webpack with HTTP/2 for a more detailed description of the issues involving HTTP/2.
If you use npm or Yarn, it shouldn't really matter if the dependencies are nested—your frontend dependencies will all be bundled anyway with Webpack/Browserify, so the main cost of using nested packages is that it takes up more space and more download time.
Since npm v3 and Yarn can do flat installs, there shouldn't be any issues with that anyway. In short: you probably can do it, and many other people are doing exactly that.
In recent days, there is an upward trend in the popularity of Yarn and its mainly due to couple of things different from npm.
One, it’s 100% deterministic i.e if you run yarn from any state, any time, 1000x times, it will still work the same way all the time. npm’s installs are nondeterministic. If you run it from various states, it will install different ways.
Yarn does some better caching too. In fact, it does it so well you’ll see a significant reduction in your install times. You can see 10x reduction in install times for big application.
Yarn also locks down your dependencies by default. It’s possible to do this with an npm shrinkwrap command but if you’ve ever had to maintain one of those, it can be messy.
Lately I have been wondering if there is any way to use bower or npm only as a consumer.
Let’s say I am not really interested on developing the package further, but simply using it on my website/application.
So as I would first think:
npm install jquery
I have tried with the flag --production but the same structure was downloaded.
However, that brings me a huge tree of files and the only one I would need is the jquery/dist/jquery.min.js file.
Same goes for bower:
bower install jquery
Again, an expensive list of files, including src folder with a lot of dev-only related files.
I am sorry if I am wrongly assuming package managers behaviour here, but it would be interesting to know how to use these package managers as a simple end-user instead a developer in order to keep my project dependencies updated.
At the moment, I feel that it's just too much for what I need, and that by simply copying jquery.min.js over to my project src folder, it would be much cleaner/simpler.
If the concept of both npm and bower is different and someone can point it out it would be appreciated as well as any tips for an alternative package manager that only imports essential production files.
Apparently Volo does exactly what I was looking for following a concept where JS libraries should be kept as one single JS file.
Here, more information about the project’s design goals.