This PR allows a way to use nitro or nitropack as a dependency and import the same.
Context
With access to nitro npm package (thanks to @jgermade and @danielroe) we can adopt using a shorter name across.
I had some doubts about this from https://github.com/unjs/nitro/issues/1362 mainly because we cannot use @nitro/ namespace in npm but with structure overhaul (#2473) and adoption of subpath exports, this is no longer a concern + usage of subpaths gives much more reasons that more end-users would benefit from explicit imports in their codebase rather than usages of a zero-dep CLI utility.
Approach
Adoption is tricky. We have a lot of current users that depend on nitropack as canonical and nitro can be only versioned for >3 to avoid conflict with the previous state.
This PR:
Add builder configuration to have interchangeable import from nitro or nitropack
Adds an automated script to generate a virtual mirror package
The virtual mirror package does not copy but reexports subpaths. This is to ensure in mixed scenarios, we don't duplicate bundle and install sizes.
Mirror dependency
The mirror package needs to have a dependency on the main package. Using peerDependencies is ideal because can help to dedup, but it turns out in cases like using npm: alias package managers show strange behavior and won't install! So it main package is in the dependencies of the mirror package.
Nitro 2.x (current)
Nitro 2.x, will use nitropack as canonical as before to avoid any changes but only supports nitro/ subpath import aliases that will redirect to nitropack/ for forward compatibility.
We release nitro@2.x.y-nitropack-mirror (with 2.x tag) and nitro-nightly@2-compat for forward compatibility.
Nitro 3.x (next)
Nitro 3.x, will use nitro as canonical and redirect nitropack/ subpath imports.
We release nitropack@3.x.y-nitro-mirror (with the latest tag) and nitropack-nightly@3.x.y-nitro-mirror for backward compatibility.
TODO
(postponed) type augmentations should work via nitro/nitropack/nitro/types and nitropack/types regardless of canonical (nitro{pack}/types)
TLDR
This PR allows a way to use
nitroornitropackas a dependency and import the same.Context
With access to
nitronpm package (thanks to @jgermade and @danielroe) we can adopt using a shorter name across.I had some doubts about this from https://github.com/unjs/nitro/issues/1362 mainly because we cannot use
@nitro/namespace in npm but with structure overhaul (#2473) and adoption of subpath exports, this is no longer a concern + usage of subpaths gives much more reasons that more end-users would benefit from explicit imports in their codebase rather than usages of a zero-dep CLI utility.Approach
Adoption is tricky. We have a lot of current users that depend on
nitropackas canonical andnitrocan be only versioned for>3to avoid conflict with the previous state.This PR:
nitroornitropackThe virtual mirror package does not copy but reexports subpaths. This is to ensure in mixed scenarios, we don't duplicate bundle and install sizes.
Mirror dependency
The mirror package needs to have a dependency on the main package. Using
peerDependenciesis ideal because can help to dedup, but it turns out in cases like usingnpm:alias package managers show strange behavior and won't install! So it main package is in thedependenciesof the mirror package.Nitro 2.x (current)
Nitro 2.x, will use
nitropackas canonical as before to avoid any changes but only supportsnitro/subpath import aliases that will redirect tonitropack/for forward compatibility.We release
nitro@2.x.y-nitropack-mirror(with2.xtag) andnitro-nightly@2-compatfor forward compatibility.Nitro 3.x (next)
Nitro 3.x, will use
nitroas canonical and redirectnitropack/subpath imports.We release
nitropack@3.x.y-nitro-mirror(with thelatesttag) andnitropack-nightly@3.x.y-nitro-mirrorfor backward compatibility.TODO
nitro/nitropack/nitro/typesandnitropack/typesregardless of canonical (nitro{pack}/types)