Highlight.js: Won't work when installed from npm.

[pgn-vole]

The client side version seems to not be included inside the npm package of the library.

When trying to load node_modules/highlight.js/lib/highlight.js an error is thrown :

Uncaught ReferenceError: module is not defined.

I guess the client side version of the library should be packaged with it so that the module can be installed from npm.

[Sannis]

npm is desined for server-side usage. You can use npm version with broserify or use third-party bower/composer/components package of highlight.js, e.g. https://github.com/components/highlightjs.

[pgn-vole]

I don't think npm only targets server-side compoments.

They actually even have a blog post about front-end dependencies management with npm.
http://blog.npmjs.org/post/101775448305/npm-and-front-end-packaging

[isagalaev]

It's not about the npm itself, it's how highlight.js is packaged. We currently provide:

• a server-oriented npm package,
• a pre-built limited browser version on two CDNs,
• a download mechanism for creating custom browser packages.

We also encourage people invested in other packaging/distribution solutions (bower, browserify, etc.) to take our source and do packaging downstream. We have no control over those.

The specific problem why we don't want to provide a uniform package everywhere is size: nobody wants a 300K script in a browser, while on the server nobody cares about the size.

[pgn-vole]

You could still keep the library modularized.
Providing a front-end package does not necessary mean a uniform package. One could add a script tag for the core file and other for any languages needed.

[isagalaev]

I don't doubt it's technically possible. But we can't maintain packages for all the modern competing packaging/distribution systems in JavaScript. In fact, I'd be glad to hand over maintenance of our current npm and cdn packages to someone else but there's no volunteers.

There's also one more complication with what you're suggesting. Providing the core library + languages as separate files is suboptimal for the browser (while we're all waiting for HTTP/2 to fix that), so you have to have some system of bundling files together. And the problem is that everyone wants a slightly different set of files. I don't think any static publishing system can do that.

[kilianc]

My two cents here are, I should be able to load languages + core file in the browser as is. Then is my responsibility with my own pipeline to merge them together. CDN + custom packaging is a different thing. I need to be able to use this in a browser and I don't see any reason why this can't be done. Tons of libraries do the same.

[kilianc]

For example, just adding an NPM friendly link on the custom build page would make lots of people happy.

[kilianc]

gonna leave this here for whoever wants to use it:

gulp.task('hjs', function (done) {
  var opts = {
    cwd: __dirname + '/node_modules/highlight.js'
  }

  var npmInstall = spawn('npm', ['install'], opts)
  npmInstall.stdout.pipe(process.stdout)
  npmInstall.stderr.pipe(process.stderr)

  npmInstall.on('close', function (code) {
    if (0 !== code) throw new Error('npm install exited with ' + code)

    var build = spawn('node', ['tools/build.js', '-n', 'json'], opts)
    build.stdout.pipe(process.stdout)
    build.stderr.pipe(process.stderr)

    build.on('close', function (code) {
      if (0 !== code) throw new Error('node tools/build.js exited with ' + code)
      done()
    })
  })
})

worked for me

[isagalaev]

@kilianc, could you clarify this bit please:

I should be able to load languages + core file in the browser as is. Then is my responsibility with my own pipeline to merge them together.

These two seem to be contradicting: you either want to load files in the browser as is _or_ to run them through a pipeline, no?

CDN + custom packaging is a different thing.

Files on CDN are the files that you can load in the browser as is, why doesn't it work in your case?

I'm not trying to defend any "true" way of doing things, I simply want to understand what people want and what doesn't work for them right now.

[kilianc]

@isagalaev only prod uses concat and minified assets, most of us use useref as part of the pipeline in order to achieve this, or some other gulp/grunt/foo task.

CDN and merged files are a good thing, but I don't see the downside of having modularity, it's quite the opposite indeed, there is no reason to not have modularity.

The CDN can easily distribute a simple concat + minify. At this very time I can't download one file per language from the CDN + core.

[isagalaev]

there is no reason to not have modularity.

I wish everyone would just stop sliding into this philosophical debate :-). Nobody is against modularity per se, the questions is how to do it exactly.

The CDN can easily distribute a simple concat + minify. At this very time I can't download one file per language from the CDN + core.

Uhm… That's exactly what's already on our CDN:

<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/8.6/highlight.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/8.6/languages/less.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/8.6/languages/scala.min.js"></script>
<script src="//cdnjs.cloudflare.com/ajax/libs/highlight.js/8.6/languages/any-other-language.min.js"></script>

One caveat: highlight.min.js is not a pure core, it's a bundle with common languages. But it shouldn't be a problem, I believe?

[kilianc]

:) it kinda is. Cool thing the CDN already works that way! I got confused obviously :)

Just adding a package.json to the custom builds will solve a lot of trouble, right ?

[isagalaev]

Just adding a package.json to the custom builds will solve a lot of trouble, right ?

How? Thing is, the "trouble" is different for different people: some want files from GitHub master to work in the browser as is, some want this from the npm package, some want the bower package, etc. And everyone expects to find docs in different places too :-). It's hard for me to appreciate all these problems myself as I happen not to use the library in any of these ways.

So in your case, where do you expect to find a package.json and what problem it should solve?

[kilianc]

@isagalaev I guess you just decide, we just need npm to work and to be able to select the languages we want. It's obviously impossible to publish on npm all combinations of languages.

People want files to work on GitHub master? Thats ok, but what files?

My suggestion is that github must be the place for source files not builds. You can have a pipeline to upload builds to the builds sections if needed.

On npm we should be able to find alla languages and core available as single require or src for the browser. Concat + minify has to be developer responsibility or CDN responsibility.

The final cherry is to make custom build installable using npm.

[bfintal]

Note that @kilianc's gulp code doesn't work right after installing via npm:

Error: Cannot find module 'highlight.js/tools/build.js'

The build script is not included in the npm package

[randre70]

2019 and still not fixed. Please reopen the issue. I try to install typedoc which is running server side.

Ignore me: existing related issue https://github.com/highlightjs/highlight.js/issues/1984