nathanjhood
commented
1 month ago It doesn't sit right with me, to have to publish experimental builds to the npm registry, where it is impossible to unpublish, just to test my project. Not least of all, if anybody were to try it out themselves without being aware of experimental release versions.
I believe that it would be possible to acquire esbuild-scripts over git instead from the npm registry now, since I removed the prepare command. I think that this command was the culprit of my test project's CI failures.
On the other hand, then you'd have to cd into the node_modules/@nathanjhood/esbuild-scripts directory yourself, run the build command, and link the CLI back to the bin directory.
I could add postinstall but this did not seem to work in previous tests, when I was consuming the package locally. Now that the mechanism has changed (I'm test-consuming from the npm registry instead of locally), this might give a different result.
As if learning ECMA, TS modules, NodeJS and browser, React/React-DOM/React-Native-Web, WebPack, and ESBuild wasn't enough fun, here comes npm to really spoil us at the finishing line! :laughing:
Published to npm registry under version 0.0.1
Now, it is possible to
yarn add @nathanjhood/esbuild-scripts.Reason: the package was not installing correctly when acquired over git.
The problems were numerous, and no fun to debug, since they only happened over remote CI runs and never locally.
I was trying to consume the package via
git+ssh://git@github.com/nathanjhood/esbuild-scripts, but the CI doesn't have the access without generating a token...When changing to
https://github.com/nathanjhood/esbuild-scriptsfor the package link, suddenly the pipeline failed at the point ofyarn install... I was just about able to determine that I should not have been usingprepareas mentioned in a recent PR, because this was somehow causingesbuild-scriptsto do its' own install in its' own directory, undernode_modules... there were multiple instances of packages being linked, etc... messy! All of which worked locally, but not remotely... (actions cache was not finding the "sub"-packages foresbuild-scriptsto build itself locally)In the end, I figured it best to clean up and publish what I have (only the build script, currently) - because I was otherwise facing a major (major) Catch 22 over the following:
import/exportsyntax and TS)So, I will come up with a versioning strategy to allow actual supported minor releases (and hopefully tweak releases), but try to keep some scope for experimental releases, which are required in order to test this particular project and thus validate that the update is good for the more regular consumers.
I've deliberately not strayed far up from the semver 0.0.0 so far; the version in the npm registry is 0.0.1, and I'll likely suggest any potential users to pick up minor version increments - 0.1.0, then 0.2.0, and so forth, leaving the third digit for beta testing.
Once I've established a suitable plan, I'll post it here and in the README.