I create a yeoman generator to help myself with front end development.
The problem is, our development environment, framework, plugins are changing so fast...
I have to update dependencies in the package.json in yeoman generator's template directory.
But, usually the package.json in yeoman generator is renamed like _package.json, because of the generator, so I cannot do just npm update.
So, I'll ask you what is the best way to update node modules in _package.json.
Thanks.
For what it's worth, npm update just update dependencies to the latest version matching your package.json dependencies semver ranger. It won't update the file itself.
To know which dependencies are outdated, you can either use npm outdated or a tool like david.
What I usually do with my project is to run one of these tools on a newly generated project. This might not seems ideal, but it's actually the best way to go because:
You ensure your generator is still working (things can break overtime if we're not careful)
You'll be able to test the new versions against your project and see where you need to fix your code so it work with latest release and breaking changes.
Also, npm using semver to set versions, this mean you only need to bump dependencies when a new major version is released. This tends to not happen all that often.
#Simon
Thank you for mention that I misunderstood the behavior of npm update.
Now I do the following step to update _package.json in generator.
create project from the generator yo generator-name
update package.json use npm-check-update.
ensure everything goes ok.
copy package.json into _package.json in generator
But I want to do this like
automatically update package.json in generator
start new project
ensure everything goes ok
I'm not sure this is the best way though...
Related
I created a new project with Rails 5.1 and I want to use webpacker to manage my react dependencies. The problem is after installing webpacker it creates a huge 130Mb+ dir node_modules with every possible node_package. This does not make sense as default behavior. How can I configure Webpacker to only keep the packages I'm actually using. I have searched for this issue in every way I could and I did not see any answers that made sense
Install what you need via yarn add, they will be listed in your package.json. Once you run assets:precompile (which will also run webpacker:compile) or just webpacker:compile, the public folder will be populated the compiled assets you are going to need to run the app.
Like Tamer says, node_modules should be in your .gitignore file. In dev, you will see all the node modules due to existing dependencies but that doesn't mean they are going to be used.
In summary, don't worry and rely on yarn.
I don't have much experience with new npm/yarn/webpacker crazyness in Rails 5. So what's the correct way to bundle assets plus their dependencies (like bootstrap 4, for example).
Before it was just a matter of moving entire downloaded js library in /assets and calling it a day.
Let's assume I want to include this datepicker in my Engine: https://github.com/chmln/flatpickr
How do I set it up? Thanks.
Did you get anywhere with this?
It seems there needs to be a solution where the host application can pull dependancies from an engines or gems YARN package.json.
That way it could merge all YARN dependancies together with its own and check if there are no conflicts, if not - Happy days.
A possible workaround is to copy the dependancies over from node_modules into the asset pipeline. This is pretty much the same as what was done previously apart from now rather than looking through each file to find the dependancies and there versions you can just look in package.json.
Once an app has been created with a Yeoman Generator, is there a way to find which version of the generator was used ?
And subsidiary question, if a newer version of the generator exists, is it possible to upgrade my existing app ?
I've just tried yo webapp, if you look at the first line in Gruntfile.js you will see
// Generated on 2013-12-11 using generator-webapp 0.4.4
I don't think you can update your app with a more recent version of the same generator, since the generator creates a folder structure and a starting point with packages and configurations it would easily conflict.
Generally speaking you are getting a starting point from the generator, upon which you build your application, if you are in need of different packages you just proceed from the starting point in your direction, adding packages, components, etc...
When looking at bower.json, I assume putting things in devDependencies is the recommended way to deal with things such unit testing dependencies. I'd like to use qunit as my testing framework, but I guess it should apply to other frameworks as well.
The problem I have is that when I put qunit in devDependencies, it doesn't get picked up when building vendor.js. That's expected, but then how do I go with asking brunch to include it? Obviously, I'd prefer to have test-vendor.js where I'd have dependencies + devDependencies, while keeping devDependencies out of vendor.js.
I have this in config.coffee:
exports.config =
# See http://brunch.readthedocs.org/en/latest/config.html for documentation.
files:
javascripts:
joinTo:
'javascripts/app.js': /^app/
'javascripts/vendor.js': /^(bower_components|vendor)/
'test/javascripts/test.js': /^test\/(?!vendor)/
'test/javascripts/test-vendor.js': /^test\/(?=vendor)/
Obviously, the last line wouldn't pick up any bower_component items as-is. Any suggestions here?
I saw this ticket:
https://github.com/paulmillr/read-components/pull/7
but it looks it's still up in the air.
This SOq:
Is it possible to split production and development Bower components?
suggests there's no way to do it from bower side at the moment.
Until this is implemented natively in Brunch, you can hack around it like this, so long as you aren't using Windows:
Add quint and other test dependencies to devDependencies in bower.json. They will now be managed under bower_components.
Add a symlink for each test dependency from your test/ directory to the relevant file under bower_components, eg:
ln -s ../bower_components/qunit/qunit.js test/
The dependencies will then be included in your unit-tests.js.
When brunch supports devDependencies, you can delete the symlinks.
See Ignore directories in brunch production build
You should be able to do something like:
overrides:
production:
conventions:
ignored: /[\/\\]_|bower_components[\/\\]qunit/
And then generate your production build with brunch b -P (brunch build --production)
How to update many plugins version when old plugin's version had manual changes in project?
Is there any tool available for doing this?
or tell proper method for updating ruby plugin version if some plugins may have manual changes done before in the older plugin's version.
Best method when a plugin is required or preferred *might be to copy out the old plugin to a dummy directory for reviewing later, then
uninstall the plugin, (script/plugin uninstall plugin_name)
install the old (but unmodified version) plugin (script/plugin install plugin_name_source_address) - likely either from rubyforge or github
review against the saved version you put in the dummy directory using an editor capable of differential display (that is, which allows you to compare two files for variations. Notepad++ is one freebie that will do this, but there are a ton of editors that allow diff views)
(this may or may not be something you can script. idk. I'm not that good, but I don't know of a tool that will do it all for you)
do another uninstall on the plugin to clear it out, since it's job is done,
install the new version of the plugin (script/plugin install plugin_name_source_address)
and finally edit the new plugin as necessary to accommodate any customization that was performed by you or some third party to the original utility.
I say as necessary because some of the customizations may not even be required in the newer version, although I can't say for sure...
finally, once all your patches are re-added to the new plugin and it's been tested and verified, either delete the dummy directory or archive it for future reference.
See, and I didn't even cop out with a bundler answer. You DID ask for assistance with a plugin, right? ;)
I'm not quite following you, but surely but that's what the Gemfile is for?
Take a look at Bundler
Try to run "$gem install rails"(it will install the newer version of rails) and then install watever the gem it asks finally run "$bundle install"