You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
currently nuxi is a single executable that inlines all its dependencies. this is great. makes a difference in speed when initialising a new app. (it also opens the door to future auto-updating of nuxi, etc.)
but there are also some problems.
performance: when added as a dependency of nuxt, which is the main use case for nuxi, this is totally duplicated content as nuxi shares its dependency set with nuxt
security: bug fixes in nuxi's dependencies require a new release in nuxi, and in some cases several releases. for example, a bug fix in lib-a might require a new release of lib-b (if it's inlining lib-a as well) and then nuxi would have to bump both dependencies and rerelease
I would like to experiment getting the best of both worlds, by reducing nuxi scope so it is smaller and leaner for the key features it needs, and creating an additional package that does not inline dependencies, which will be used within nuxt
here's the proposed strategy:
The content you are editing has changed. Please copy your edits and refresh the page.
the last point would entail dropping subcommand dependencies from nuxi that rely on an installed nuxt instance, so e.g. dev command could call the @nuxt/cli installed within the nuxt project, much as we already load kit from that project
this would leave nuxi as a hyper-minimal cli for initialising a project, with its dependencies still inlined, but the nuxi binary that most users would end up using in their project would in fact be provided by @nuxt/cli with the corresponding benefits.
note:
users might have manually installed nuxi - they won't benefit from the reduced disk space usage, but there will be no breakage
nuxi and @nuxt/cli versions might be different so it will be important for (as much as possible) nuxi to defer to the installed @nuxt/cli for parsing args, etc.
I would welcome feedback from the team + community, in identifying possible issues and figuring out possible solutions for any unforeseen ones.
The text was updated successfully, but these errors were encountered:
currently
nuxi
is a single executable that inlines all its dependencies. this is great. makes a difference in speed when initialising a new app. (it also opens the door to future auto-updating ofnuxi
, etc.)but there are also some problems.
nuxt
, which is the main use case fornuxi
, this is totally duplicated content asnuxi
shares its dependency set with nuxtnuxi
, and in some cases several releases. for example, a bug fix inlib-a
might require a new release oflib-b
(if it's inlininglib-a
as well) and thennuxi
would have to bump both dependencies and rereleaseI would like to experiment getting the best of both worlds, by reducing
nuxi
scope so it is smaller and leaner for the key features it needs, and creating an additional package that does not inline dependencies, which will be used withinnuxt
here's the proposed strategy:
Tasks
the last point would entail dropping subcommand dependencies from
nuxi
that rely on an installednuxt
instance, so e.g.dev
command could call the@nuxt/cli
installed within thenuxt
project, much as we already load kit from that projectthis would leave nuxi as a hyper-minimal cli for initialising a project, with its dependencies still inlined, but the
nuxi
binary that most users would end up using in their project would in fact be provided by@nuxt/cli
with the corresponding benefits.note:
nuxi
- they won't benefit from the reduced disk space usage, but there will be no breakagenuxi
and@nuxt/cli
versions might be different so it will be important for (as much as possible)nuxi
to defer to the installed@nuxt/cli
for parsing args, etc.I would welcome feedback from the team + community, in identifying possible issues and figuring out possible solutions for any unforeseen ones.
The text was updated successfully, but these errors were encountered: