Closed JayaKrishnaNamburu closed 11 months ago
I think that line in the build system should be .link()
and not .install()
. Install acts like npm install
, which does do updates. Note freeze
has been deprecated for instead having different commands which are sometimes mutating and sometimes not. install
is always mutating. link
is like the old freeze.
Perhaps this is confusing - we should verify before the next generator major as this is what we implemented with @Bubblyworld based on various discussions about aligning the CLI behaviours.
Phenomental work tracing this down and building out the workflow on this. So amazing to see it coming together.
I think that line in the build system should be .link() and not .install(). Install acts like npm install, which does do updates. Note freeze has been deprecated for instead having different commands which are sometimes mutating and sometimes not. install is always mutating. link is like the old freeze.
Got it, but the link
still needs a specifier to manually link them. The flow there is little bit confusing. Can we open a discussion on that on the cli
repository ?
install
after passing a inputMap
? ( We should't as it is updating the dependencies)generator.link
? (But the link is expecting individual specifiers, so not sure how to use that)cli
should preserve those lock files from the generator and write them to local. And read them again when loading the generator right ?Should i create a discussion thread on the cli
repo to discuss all these with examples would be very great 😄
So for now, i released the -r
and -m
support for the build in cli
https://github.com/jspm/jspm-cli/releases/tag/3.1.2
So the vs-code can use them and start working. Here is a PR for the upgrade. Merging it, will unlock the build failure issue on the vs-code plugin 👍 https://github.com/jspm/jspm-vscode/pull/20
The issue for the failing build is, because of a version bump that happened for
@babel/helper-module-transforms
package after the last release ofjspm-vscode
plugin which is0.2.1
https://github.com/jspm/jspm-vscode/commit/8c4aa6d96d1dd8a7416afd27d3ccbd1606df2cad. All the maps i created started failing, so took thepacakge-lock.json
from the 0.2.1 version of the vs-code plugin and matched those versions to make things work and fix next.The build goes well when we are using
@babel/helper-module-transforms@7.21.4
and failing when it uses the latest version of the package@babel/helper-module-transforms@7.23.2
. I haven't looked deeply on what's changed between the two versions of this package.I created a new map using
it created a map using
@babel/helper-module-transforms@7.23.2
which is expected as it falls into the@babel/core
range of the@jspm/generator
.Then i updated the map using to use
@babel/helper-module-transforms@7.21.4
usingWhich gives us the current map in the PR
https://github.com/jspm/jspm-vscode/blob/c5136a0b87181fde37533149b6bbcc628def550a/importmap.json
Now i just used the build command to generate the build.
Which should work without any issues as we already stated the version to be
7.21.2
. But it fails again, turns out The step where we load theimportmap
from the file into the generator and install it for the build to continue. Is updating everything again See it here in thejspm cli
https://github.com/jspm/jspm-cli/blob/main/src/build/rollup-importmap-plugin.ts#L18-L23I am not sure if the
freeze
shouldn't even update theminor
andpatch
versions too. But, it's happening right now.So, i opened a new PR on the
cli
to make sure we pass resolutions and use them again at the step of installation. https://github.com/jspm/jspm-cli/pull/2556So, the new build command becomes
Which enforce the resolutions when using the existing map without updating the
minor
andpatch
for the package.Steps, we first need to release the cli and use it here and we are all good. First implementation of the
jspm build
command in real time 😄fixes #17