Open scscgit opened 3 years ago
Thanks for PR and explanation @scscgit. I think it is nice to use npm-check-updates for npm
users. For yarn, we have a built-in yarn outdated command and yarn upgrade-interactive which is probably safer when it comes to updating major version of several dependencies.
Also as a best practice, users should use a system like https://dependabot.com/ or https://github.com/renovatebot/renovate that can handle most of these challenges for lock-file maintenance, separating major dependency upgrades from the rest with a nice interface.
PS: I will also make sure new nuxt3 CLI (usable for nuxt2) will have some built-ins too so we don't need to make use of several packages and having a robust upgrade syustem.
Thanks @pi0, yeah I don't have experience with yarn's upgrade-interactive
, so it may be a better option for projects that select yarn
if it satisfies all the updating needs. I'm looking forward to the new Nuxt CLI options; hopefully they'll even replace npm-check-updates
as a standalone tool that'll become a top recommendation in all search results, becoming a new de-facto standard :)
When it comes to dependabot and renovatebot, sadly these can't be used standalone, for example if we work on private / company projects that can't integrate with receiving public PRs. There may be also a few opinionated reasons why someone wouldn't agree with their workflow, preferring to have more control over their infrastructure; so even though the trend looks nice, we're still very dependent on these specific companies matching our needs, and needless to say, it steepens our learning curve.
When it comes to dependabot and renovatebot, sadly these can't be used standalone, for example if we work on private / company projects that can't integrate with receiving public PRs.
Renovate bot is opensource and can be self-hosted in your own infra: https://docs.renovatebot.com/self-hosting/ and also have a standalone npm cli that we can potentially use as a unified option.
BTW I agree there might be opinionated reasons to use npm or yarn directly for managing dependencies and doing something like this PR. Maybe we can add an option in devtools prompt to enable?
/cc @rarkins Kindly if you have some thoughts to add :)
Yeah it'd be a good idea to move these scripts under a devTools
option unless they match a use-case that's preferred for all projects (e.g. if a workaround is needed for any contributor to easily check or test new versions locally). Feel free to choose the specific string message contents, together with the yarn or renovate CLI variants, and I'll update the PR for a first iteration. There are too many options with various downsides, so it'll be great to converge on a consensus that matches everyone's intentions in the form of a standalone tool. (We don't want to put users in impossible situations like how npm often does it by default.)
Something very simple you can do is install Renovate with dependencyDashboardApproval: true
in settings. It will then do nothing but create a "Dependency Dashboard" issue which lists all the available updates, with a checkbox next to each. No PRs will be created by default. Example of how it looks: https://github.com/renovatebot/renovate/issues/2958
From experience I'd say that in general:
Something else we do is address upgrade hesitancy by providing "Merge Confidence" with PRs. We're looking at how to incorporate those into the Dashboard too, so that you can see if the upgrade is unlikely to break anything before you tick the checkbox to request the PR be created.
Close this as we're using Dependency Dashboard
now
@clarkdo Are you sure we don't want to provide users with the option of standalone updates, at least for npm
(e.g. as a devTools option if not automatically) where it requires a hacky solution that Nuxt users have absolutely no way of figuring out by themselves? I think you're referring to PR #848 with the Dependency Dashboard
, but that is a PR against create-nuxt-app's own configuration, whereas my PR is for a code generated for new projects. Also as far as I know, the Dependency Dashboard
isn't set up for generated projects by default either.
Sorry for the misunderstanding.
I’ve reopened the pr, but I still want to hear more thoughts from other team members @nuxt/framework, this change looks good, but I’m not sure if it’s far away from the original intention of the generated project, it’s a useful script, but it’s kind of out of nuxt scope, we may avoid introducing too many nuxt irrelevant features. Actually I’m thinking if current crate-nuxt-app is having too many options, maybe we should refactor and focus on nuxt core functionality and ecosystem in future.
we may avoid introducing too many nuxt irrelevant features
I understand the sentiment, but to reinforce some motivation anyway, I'm still hoping we'll continue on the same trajectory and focus on DX in general in a near future rather than closing our eyes in front of some blatantly obvious problems that everyone experiences, because there don't seem to be any other projects with a more holistic focus. Nuxt's approach of offering a opinionated zero-config setup that "just works" is a dream come true, so with a growing technological complexity (and laziness of library maintainers), it's vital for the sake of our efficiency that someone keeps taking on this responsibility (even if only for a subset of combinations, e.g. I'd understand if we explicitly deprecated npm fixes at some point) :) It goes a long way if we at least keep a neutral stance and accept features that have "negligible risks of supporting effort", its mindset will have consequences in the following years. One of our sins as devs is that we often feel like a problem is just temporary, yet in the end never solve it despite users eagerly waiting every day. (It especially means not documenting the scope of what will be added.) For example, it's worth adding update scripts even if we plan to introduce a new CLI tool later, because even then we may find excuses to postpone adding it for different reasons.
That said, the responsibility to setup any tools and scripts unrelated to Nuxt could be definitely delegated to a separate scaffolding project and used as a dependency instead.
Developers currently don't have any recommended means of updating major versions of dependencies, because the "official" commands like
npm update
only function with varying limitations and within the scope of semantic versioning. I'm currently aware of https://www.npmjs.com/package/npm-check-updates being a de-facto standard to perform this kind of routine maintenance, so I'd suggest for Nuxt to make a consensus decision if this is a correct default approach for new Nuxt developers or not, because we need to acknowledge how developers are currently forced to accept a workaround like this. In the best case scenario, we'd be able to suggest a better alternative without resorting to a third party library.As with everything, there are definite reasons why we shouldn't ambiguously leave this setup to be arbitrarily done by the developers, including but not limited to enforcing best practices; for example:
npx
without--no-install
without knowing which version is being used, or not documenting it at all, assuming that everyone will figure out some way on their own (which usually means just usingnpm update
or manually checking registries, and then having projects get outdated with a lack of any automation),--packageFile package.json
based on https://github.com/raineorshine/npm-check-updates/issues/136#issuecomment-155859050 (https://github.com/raineorshine/npm-check-updates#known-issues) may be required depending on the used terminal (Git Bash on Windows); and it's easier to keep track of which workarounds are still needed if a generator tracks them,yarn
|npm install
is included as part of the command in a correct order, so that we don't have to double-check anything.There is one more unintuitive matter regarding the lock file, as I couldn't find a way to force
npm
to update all the transitive dependencies without literally deleting the entirenode_modues
with around 100k files together with thepackage-lock.json
before runningnpm install
, otherwise it just found and re-used the obsolete dependencies as a successful semver match. Not only have users no way of figuring out that this is the default behavior, but there is also no direct solution, because deleting this directory takes an enormous amount of time (even on SSD), and it's also cumbersome to define a deletion script as portable between OSes. There's even a suggested hack of actually moving the directory to some other (temp) directory first before attempting to delete it, so that you don't have to wait so long before you start the re-installation.echo You may need to first remove both `package-lock.json` and `node_modules` before running `npm install` to install latest transitive versions &&
As a postfix, I've included another script that updates browserslist, which seems to be a best practice based on https://github.com/browserslist/browserslist/issues/492. In addition, this place may be useful in the future for other libraries that also include their own update scripts; for example,
&& openapi-generator-cli version-manager set latest
One of advantages for keeping the
update:check
as a separate script, on top of CI automation, is that users can also use it as a source of truth for any exclusions. For example,-x vue-trumbowyg
would be required because this wrapper uses Vue 3 on the latest version. Because it may not be obvious at a first glance that this-x
is even supported, it'd be preferable if we could document it as part of best practices for updating libraries; or if we could at least put there some placeholder. For now I'm omitting this until everyone agrees.Also note that
npx
is extremely slow and always re-installs the dependency (though it may not be an issue in latest versions), so it'd be reasonable to instead suggest installing & locking this as part of devDependencies. At the moment I think it's worth the cost, because we don't run these scripts on a daily basis.