install 9.15.1 fail

[fengmk2]

Error: ENOENT: no such file or directory, chmod '.../node_modules/_highlight.js@9.15.1@highlight.js/tools/build.js'

missing tools/build.js file.

[fengmk2]

It cause by ee2ae80#diff-b9cfc7f2cdf78a7f4b91a753d10865a2R25

[czy88840616]

it cause error in npm install.

[dindurthy]

+1

[zomble]

Same here.

[marcoscaceres]

Apologies, will fix in ~2 hours unless someone wants to put together a pull request quickly.

[lixiaolihua]

+1

[czy88840616]

Could you change latest tag in npm to fix this problem quickly?

[mchaov]

+1

[sirjones]

+1

[serjout]

+1

[nbivanov]

+1

[hartja]

+1

[XKhumalo]

+1

[sirjones]

For those in a hurry (Like I was). You can download the repo and install it locally with npm and it works fine

[bookofjames]

+1

[EndyKaufman]

+1

[JessicaSachs]

Also a work around for dependent packages is to install 9.15.0 as a peer dependency via npm i highlight.js@9.15.0 -D

[grigoreme]

+1

[RedTailBullet]

So it's not fixed yet?

[zhaoqin-github]

Waiting for a fix...

[marcoscaceres]

Starting to work on the fix. I’m muting the bug, as it’s getting spammy. If you’d like to subscribe to the bug, to be notified when it’s fixed, please use the subscribe button.

[marcoscaceres]

Ok, can a few folks try:

npm install github:highlightjs/highlight.js#fix_build
npx hljs 

Let me know if that works...

[zhang-shengping]

npx hljs 

I have tried it, It works for me.

[marcoscaceres]

@isagalaev is right. We maintainers do the best we can, and it's definitely not part of our day job. There are a few solutions people can use to protect themselves from these kinds of events:

• lock dependency to a particular version number.
• rely on a service like https://greenkeeper.io - which will check that an updates doesn't break your build.
• always test before updating, don't blindly just go for "latest".

[ljharb]

One suggestion that might make it easier for maintainers would be to use a prepublish script, rather than having a separate release script - that way, npm publish can't proceed until that script passes.

[marcoscaceres]

@ljharb, that's a good suggestion. I'd also like to write a better check on TravisCI. I wasn't expecting the package to be stripped of some of its contents.

I'll write an incident report and publish it here describing what happened and what we will try to improve to prevent this from happening again.

Again, this is a call for the community to help us (we literally run this project on a skeleton crew... putting in maybe 1 hour a month to keeping it running). I'm definitely not an expert on NPM - so help from folks with more experience would be greatly appreciated to keep this project healthy.

[marcoscaceres]

Folks, I've published 9.15.5.... any better? 🤞

[das-peter]

@marcoscaceres Our build system is all green again - got the latest 9.15.5 version as npm lists that version now too.
@isagalaev & @marcoscaceres Thanks for your efforts, appreciated very much :)

[marcoscaceres]

incident report

What happened?

About a week ago we merged #1951, which made changes to the tools/build.js utility by excluding certain files (docs, demos, and other things). The PR's intention was to have a way to build a highlight bundle from the command line, but to not build the docs and demos that are not needed on CI environments.

Although we'd been thoroughly testing this binary in production in another project for over a year, we'd been installing highlight.js over a github: URL. Unknown to me, the highlight.js npm publish script only included certain files: The script is on an ex-maintainer's private server, so I'd incorrectly assumed that it was publishing the repository as is. This assumption was wrong and led to things breaking.

When 9.15.1 release went live, it was missing tools/build.js and possibly other things causing depedents to break.

What we did in response

At first, I thought the problem was that the bin path was maybe wrong. However, thanks to helpful #1984 (comment) from @netanelgilad, it was pointed out that the problem was with how the package was being published: it was missing directories/files.

As a result, I reverted #1951. However, this was insufficient because we'd changed our release script to work with the new tools/build.js. We then needed to revert some changes to the release script.

After a few bad releases, we then successfully published 9.15.5.

What we learned

Keeping in mind that the maintainers are new to the project:

• the published package does not reflect what's in the repository.

What could we do to prevent this from happening again

We need to figure out a way to pre-publish (or publish as "beta") a package, and then try to install the package in a mock project to make sure things still work as expected.

If folks have suggestion for how to do that - or what a good setup might be to test what's actually published before it goes live, I'd be open to suggestions.

[marcoscaceres]

I'll wait for a few more confirmation that things are back in a good state before closing. Will keep an eye on things throughout the day.

[zhaoqin-github]

@marcoscaceres My system can accomplish npm install now. The installed highlight.js version is 9.15.5. Thanks for you fix!

[marcoscaceres]

Thanks for confirming @zhaoqin-github.

[loooSwc]

success+1

[neilning-xc]

Quick solution: npm install highlight.js@9.12.0 --save and then run npm shrinkwrap, fix all version info into npm-shrinkwrapwrap.json file, then run npm install. It works for our project

[ljharb]

@marcoscaceres if you enable 2FA for this package (which you should, regardless) then when you run npm publish, before it actually publishes, it will print out a summary of which files will be included in the package and then prompt you for your one time password. I often use this to ensure my packages have the required files.

[ernestoort]

I can tell you it is working right now. I have a project that depends of typedoc, hence this project.

Being honest, you give me a lot of headaches today. For me today was a Murphy moment that ended with this incident today.

I'm not blaming you. This is an open source project and we have to be aware this things are going to happen.

And personally, I PREFER, 100x times, an open source project like this one that a private one with no documents.

[lifuyao]

I also met this issue yesterday, thanks for resolving it

[marcoscaceres]

Ok, seems we are good... closing.

[alasdairhurst]

If folks have suggestion for how to do that - or what a good setup might be to test what's actually published before it goes live, I'd be open to suggestions.

There are a few ways to go about this -

• Publish each release, potentially each time master builds, with a prerelease version indicated by a dash at the end: x.x.x-0
  these can be individually tested just like regular versions, but users won't pick them up by default, and it's clear that they may have potential bugs. When it's ready to release, test the latest prerelease and if it works, trim the prerelease part from the version and do a release.
• Another approach (which could be done alongside the latter) is to make use of npm tags. When you release a new version, tag with "next" rather than "latest" and test it. If it works, only then change the tag to "latest". That way even if 9.16.0 is released after 9.15.5, as long as it's marked "next", people depending on "^9.0.0" won't pick it up.