Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Require using AMD broken in 10.0.0 #2505

Closed
jlchereau opened this issue Apr 24, 2020 · 25 comments · Fixed by #2511
Closed

Require using AMD broken in 10.0.0 #2505

jlchereau opened this issue Apr 24, 2020 · 25 comments · Fixed by #2511
Labels
bug help welcome Could use help from community package/build Issues relating to npm or packaging
Milestone

Comments

@jlchereau
Copy link

jlchereau commented Apr 24, 2020

Loading via SystemJS in AMD used to work with v9.18.1. Broken in v10:

system.js:4 Uncaught (in promise) ReferenceError: hljs is not defined
    at eval (highlight.js:1566)
    at eval (highlight.js:6322)
    at eval (<anonymous>)
    at Qe (system.js:4)
    at system.js:4
    at async Promise.all (:63342/Kidoju.Widgets/src/js/widgets/index 10)

hljs is undefined when calling L1566

hljs.registerLanguage('apache', function () {
   ...
}());

In System.config.js, I have:

packages: {
    'src/js': {
        defaultExtension: 'js',
        meta: {
           '*.js': {
                babelOptions: {
                    es2015: false,
                    stage2: false,
                    stage3: false,
                },
                format: 'amd',
            },
            '*.es6': {
                format: 'esm',
            },
            '*.jsx': {
                format: 'esm',
            },
            '*.mjs': {
                format: 'esm',
            },
         },
      },
 },

A workaround for now is to add an exception in meta:

 'vendor/highlight/highlight.js': {
      // Note: AMD broken as of v10
      format: 'global',
},
@jlchereau jlchereau added the enhancement An enhancement or new feature label Apr 24, 2020
@joshgoebel
Copy link
Member

joshgoebel commented Apr 24, 2020

I'm not sure we ever were truly AMD compatible, the old init just did this:

  globalObject.hljs = factory({});

    // Finally register the global hljs with AMD.
    if(typeof define === 'function' && define.amd) {
      define([], function() {
        return globalObject.hljs;
      });
    }

IE, define a global, and then tell AMD to use that global... the new build system actually is actually behaving better (AMD wise) but the problem is now when we're trying to register the language modules there is no top-level hljs yet likely because I would assume AMD isn't (ever?) going to make one for us?

The language modules have always registered themselves via a top-level hljs global object.

So the behavior is different, but I'm not sure that's actually a problem - since it was "all globals all along" so far as I can tell. I'm not sure what the right answer is here because I don't think what we're doing before is actually correct... so perhaps someone with more knowledge can weigh in here.

@joshgoebel
Copy link
Member

joshgoebel commented Apr 24, 2020

Perhaps we should just remove our AMD support? Perhaps someone super familiar with AMD could explain what we'd have to do with the language modules to make them truly AMD compatible (hard to say if that's viable without knowing what would be required)... just going back to how we had it before seems quite broken to me.

Do all the language modules need UMD wrappers? That would be annoying.

Some language modules also have their own built-in dependencies and expect to be loaded in the proper sequence... they would not do so well if the order were randomized, etc. (the build process takes care of this by inserting the registrations in the proper order in the final web build product).

@joshgoebel joshgoebel added bug help welcome Could use help from community package/build Issues relating to npm or packaging and removed enhancement An enhancement or new feature labels Apr 24, 2020
@joshgoebel joshgoebel changed the title AMD broken in v10 Require using AMD broken in 10.0.0 Apr 24, 2020
@jlchereau
Copy link
Author

jlchereau commented Apr 24, 2020

I think the problem is in the structure of the build output file which is:

(function (global, factory) {
  typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory() :
  typeof define === 'function' && define.amd ? define(factory) :
  (global = global || self, global.hljs = factory());
}(this, (function () { 'use strict';
  const HLJS = function(hljs) {
    ....
  }
  var highlight = HLJS({});
  return highlight;
})));

hljs.registerLanguage('apache', function () { // <-- hljs is undefined when using AMD
  ...
}());

After removing all hljs.registerLanguage, AMD loading works fine and returns the hljs object to the loader.

@joshgoebel
Copy link
Member

joshgoebel commented Apr 24, 2020

Yes, I understand exactly why it is failing. The new AMD code fails to setup a global object (as it did before), so this now fails.

I'm less sure of the path forward.

This output is how the build process works (and always has). Languages are "modules" that are added AFTER the core library is setup by calling registerLanguage. This is also currently a requirement of the website builder/download tool too... the languages are just appeneded to the end of the core library.

@joshgoebel
Copy link
Member

joshgoebel commented Apr 24, 2020

After removing all hljs.registerLanguage, AMD loading works fine and returns the hljs object to the loader.

And now you have no languages, so the highlighter won't work. :)

@joshgoebel
Copy link
Member

joshgoebel commented Apr 24, 2020

From a different angle: What benefits do you gain by using AMD here vs having to declare it "global"?

@jlchereau
Copy link
Author

jlchereau commented Apr 24, 2020

I know but the problem is not with your UMD wrapper which is fine.

@joshgoebel
Copy link
Member

joshgoebel commented Apr 24, 2020

I know but the problem is not with your UMD wrapper which is fine.

Well it depends how you define the problem. :-) You could also say the wrapper is EXACTLY the problem. The old wrapper setup a global, the new wrapper does not - and as a result it fails.

@egor-rogov Any thoughts here?

@jlchereau
Copy link
Author

jlchereau commented Apr 24, 2020

From my end, I can certainly use a workaround either with SystemJS (development) or Webpack (production). I'll always find a solution. I just thought it was nice to report an issue.

@joshgoebel
Copy link
Member

joshgoebel commented Apr 24, 2020

I just thought it was nice to report an issue.

It certainly was. :-) And thanks. I'm just wondering the value of saying we support AMD when truly we don't and we register a global anyways... I have a feeling doing it "properly" might be time and effort better spent on other things...

Isn't part of the point of AMD to control/defer executing the JS modules?

Since Highlight.js has no external requirements I'm starting to wonder what AMD gives anyone here anyways? I guess you could express that other parts of your system are dependent on Highlight.js?

@jlchereau
Copy link
Author

jlchereau commented Apr 24, 2020

The issue is you are mixing modules and code outside of modules in the same file. I have also tried loading via CommonJS: same error:

Uncaught (in promise) ReferenceError: hljs is not defined
    at Object.eval (highlight.js:1566)
    at eval (highlight.js:6322)
    at eval (highlight.js:6323)
    at eval (<anonymous>)
    at Qe (system.js:4)
    at system.js:4
    at T (system.js:4)
    at U (system.js:4)
    at system.js:4
    at system.js:4

For this, simply configure SystemJS with:

'vendor/highlight/highlight.js': {
    format: 'cjs',
},

Your npm module works because it does not use the same code as the build output, highlight.pack.js. The npm module actually loads the module before loading languages:

var hljs = require('./core');
hljs.registerLanguage('apache', require('./languages/apache'));

In highlight.pack.js, the module id defined but not loaded before loading language packs, unless it has been assigned to global.

@jlchereau
Copy link
Author

jlchereau commented Apr 24, 2020

The cleaner option which I have just tested and which works is to change the structure as follows:

(function (global, factory) {
  typeof exports === 'object' && typeof module !== 'undefined' ? module.exports = factory() :
  typeof define === 'function' && define.amd ? define(factory) :
  (global = global || self, global.hljs = factory());
}(this, (function () { 'use strict';
  const HLJS = function(hljs) {
    ....
  }
  var highlight = HLJS({});

  highlight.registerLanguage('apache', function () {
      ...
  }());

  return highlight;
})));

This concatenates the file a bit differently but the result works both with AMD and CJS in addition to global = true UMD!

I have attached the working file for a diff: highlight.zip

@joshgoebel
Copy link
Member

joshgoebel commented Apr 24, 2020

But that’s currently not possible for the website builder and would also break 3rd party languages that load later and expect a global. So if we are going to solve this we can’t just solve it half way.

I think we hack it like we did before or else it seems all the language modules need to become UMD. I’m not even sure how that might work. Surely AMD supports named dependencies?

@joshgoebel
Copy link
Member

joshgoebel commented Apr 24, 2020

Do you know what the proper AMD way would be to call the registration at a later point?

Ie, how do I get the internal HLJS object back out of Amd or pass a callback that can access it?

@joshgoebel
Copy link
Member

joshgoebel commented Apr 24, 2020

So if we give our module an id (which is easy enough):

typeof define === 'function' && define.amd ? define('highlight.js', factory) :

Then I think later you could do:

if (typeof define === 'function' && define.amd) {
  define(null, ["highlight.js"], (hljs) => { 
   hljs.registerLanguage('apache',...
  });
} else {
   hljs.registerLanguage('apache'...
}

Which is kind of what I expected... But I'm wondering what we gain by jumping thru all those hoops since no one has ever seemed to mind a global in the past?

Doing this would require all the 3rd party distributables to be recompiled to also include a UMD wrapper...

@jlchereau
Copy link
Author

jlchereau commented Apr 25, 2020

@yyyc514,

IMHO:

  1. UMD loading in highlight.pack.js v10 is broken both for AMD and CommonJS,
  2. highlight is a nice piece of code and you cannot have a broken feature: fix it or remove it,
  3. your suggestion here above, is not the proper way to fix it for AMD and it does not fix it for CommonJS (I could explain but I am not sure it is worth the trouble).
  4. In the long term, modules are now part of ECMAScript and are the way forward,
  5. in the short term, most loaders including webpack can accommodate globals,
  6. so in the end this is a question of product roadmap driven by user requirements.

I would recommend:

  1. Until you have a proper fix, stick to global only to avoid misleading your users with features that do not work;
  2. Give me a few days to look at the code for building highlight.pack.js and see if I can come up with an easy suggestion to fix this. If I can, I'll make a PR.

@jlchereau
Copy link
Author

jlchereau commented Apr 25, 2020

I just realized there is a lot of custom code to build highligh.js but why reinvent the wheel? i.e. why not use webpack to build your library? cf. https://webpack.js.org/guides/author-libraries/#expose-the-library. Any specific requirements? Just asking as you might consider delaying UMD as part of your product roadmap.

@egor-rogov
Copy link
Collaborator

egor-rogov commented Apr 25, 2020

@egor-rogov Any thoughts here?

No idea. Until today I was pretty sure that AMD is for Advanced Micro Devices (:

@joshgoebel
Copy link
Member

joshgoebel commented Apr 25, 2020

Youur suggestion here above, is not the proper way to fix it for AMD

I was talking solely about how to do it "best" for AMD above... is that not how you would do it? Register the library with an ID and then make that id a dependency of the languages (which would also load via AMD)? Remember we have to support languages loaded at any time, not just those bundled with the JS file.

highlight.pack.js

Do you mean .min.js? There is no pack file anymore with version 10.

In the long term, modules are now part of ECMAScript and are the way forward,

If someone wanted to use the raw source it's all modules now and could be hooked into whatever build system, but the web library is built to a single simple file and the NPM library is built to CommonJS (require, etc), which Node still seems to be stuck on...

and CommonJS,

I'm not sure the web build has ever been CommonJS compatible (haha, and looks like it was because of how it bundled the languages - though i'm not sure the versions build by the website ever were), but feel free to correct me if I'm mistaken. Previous src/highlight.js happened to be since it ONLY included the library code, but that doesn't make sense now since that file is ES6 modules now, not a built file...

If someone wants to use CommonsJS they need to use the NPM package we provide.

@joshgoebel
Copy link
Member

joshgoebel commented Apr 25, 2020

In the long term, modules are now part of ECMAScript and are the way forward,

Agree, and when Node.js natively supports them broadly then I think we'd look at publishing an NPM package that was ES6 modules vs require... until then anyone is free to use the raw source which is ahead of the curve (since v10).

@joshgoebel
Copy link
Member

joshgoebel commented Apr 25, 2020

I just realized there is a lot of custom code to build highligh.js but why reinvent the wheel? i.e. why not use webpack to build your library? cf. https://webpack.js.org/guides/author-libraries/#expose-the-library. Any specific requirements? Just asking as you might consider delaying UMD as part of your product roadmap.

We have very specific requirements and the JS build code is all quite clear and easy to follow IMHO - it's all just functions, very little magic. You only need to know Javascript (and a bit of rollup). If we simplify it further in the future it'll likely be on top of rollup, not webpack. I've never cared for webpack; never seemed simple or intuitive to me at all.

The goal was never to ship a UMD build, just rather to "preserve" the existing AMD functionality from before... sadly I didn't realize how "hacked" it was, so we failed to do that.


If you want to explain how you feel the "proper" way to do AMD in this situation is, I will consider it but at this point I think the best way forward may be to just drop the previous hacky AMD support and not pretend to do AMD at all - and for the browser just ship a global version - which is really what we'd done all along anyways.

@joshgoebel
Copy link
Member

joshgoebel commented Apr 25, 2020

So if we just fallback to IIFE for the browser build we'll have:

/*
  Highlight.js 10.0.0 (3875088a)
  License: BSD-3-Clause
  Copyright (c) 2006-2020, Ivan Sagalaev
*/
var hljs = (function () {
  'use strict';
  ...

Just a top level variable...

@joshgoebel
Copy link
Member

joshgoebel commented Apr 25, 2020

@jlchereau Out of curiosity how were you using HLJS before? Just the default build with "common" languages built-in via AMD?

What will people's AMD pipelines do if we just switch to a pure global? Will they need to change their configs or will it just work despite not really being AMD?

joshgoebel added a commit to joshgoebel/highlight.js that referenced this issue Apr 25, 2020
- dropping support for AMD, which we never truly supported
  in the first place

  Resolves highlightjs#2505
@joshgoebel
Copy link
Member

joshgoebel commented Apr 25, 2020

@jlchereau Can you take a quick look at the PR. It falls back to an IIFE build but also hooks up the variable to module.exports if it's around. I think this:

  • Works in the browser (IIFE, global var hljs)
  • Works for CommonJS (my Node.js test file can requite it and use it just fine)
  • (therefore restoring the ability for someone to just grab the primary distributable and use it standalone with Node.js if they really wanted to)
  • Drops support for AMD which we never truly supported properly anyways

@joshgoebel joshgoebel added this to the 10.0.1 milestone Apr 26, 2020
joshgoebel added a commit to joshgoebel/highlight.js that referenced this issue Apr 26, 2020
- dropping support for AMD, which we never truly supported
  in the first place

  Resolves highlightjs#2505
@joshgoebel
Copy link
Member

joshgoebel commented Apr 28, 2020

@jlchereau Any further thoughts? If not I'm going to move forward with just supporting CommonJS and IIFE/global and drop support for AMD.

joshgoebel added a commit that referenced this issue May 3, 2020
* (build) browser build is CommonJS and IIFE (global) now
* (build) dropping support for AMD, which we never truly supported
  properly in the first place
* (build) add test to make sure browser build works as commonJS module

  Resolves #2505
joshgoebel added a commit to joshgoebel/highlight.js that referenced this issue May 3, 2020
…2511)

* (build) browser build is CommonJS and IIFE (global) now
* (build) dropping support for AMD, which we never truly supported
  properly in the first place
* (build) add test to make sure browser build works as commonJS module

  Resolves highlightjs#2505
0xflotus added a commit to 0xflotus/highlight.js that referenced this issue Jun 12, 2020
* (docs) Add Chaos to supported languages (highlightjs#2510)

* fix(parser) fixes sublanguage with no rule matches (highlightjs#2506)

* fix(parser) fixes sublanguage with no rule matches

Resolves highlightjs#2504.

* (chore) Add ESLint config and clean up the major stuff (highlightjs#2503)

* (chore) eslint:recommended
* (chore): eslint_standard
* relax eslint rules for language grammars (to discourage rewriting them in one fell swoop; I'd rather have the blame history intact)
* remove extra escaping
* clean up variables
* more camelcase

* (docs) Add Visual Basic for Applications (VBA) to supported languages (highlightjs#2512)

* (yaml) improve tag support; add verbatim tags (highlightjs#2487)

* YAML parse non-word characters as part of tags
* adds support for verbatim tags

Co-authored-by: Josh Goebel <me@joshgoebel.com>

* fix(javascript/typescript): lambda with parens in parameters fails (highlightjs#2502)

* fix(javascript/typescript): lambda with parens in parameters fails

- Fixes both JavaScript and TypeScript grammars

Fixes samples like:

    const bad = ((a, b) => [...a, b]);
    sides.every((length,width=(3+2+(4/5))) => length > 0 );

This is done by counting parens in the regex that finds arrows
functions. Currently we can only handle 2 levels of nesting as
shown in the second example above.

* allow much richer highlighting inside params
* improve highlighting inside arguments on typescript

* enh(cpp): Improve highlighting of unterminated raw strings

PR highlightjs#1897 switched C++ raw strings to use backreferences, however this
breaks souce files where raw strings are truncated. Like comments, it
would be preferable to highlight them.

- Add `on:begin` and `on:end` to allow more granular matching when
  then end match is dynamic and based on a part of the begin match
- This deprecates the `endSameAsBegin` attribute. That attribute was
  a very specific way to solve this problem, but now we have a much
  more general solution in these added callbacks.

Also related: highlightjs#2259.

Co-authored-by: Josh Goebel <me@joshgoebel.com>

* (chore) C-like uses the new END_SAME_AS_BEGIN mode

* (chore) Ruby uses END_SAME_AS_BEGIN mode/rule

* (parser) make END_SAME_AS_BEGIN a function helper

Adds a mode helper to replace the deprecated `endSameAsBegin` attribute.

The first match group from the begin regex will be compared to the first
match group from the end regex and the end regex will only match if both
strings are identical.

Note this is more advanced functionality than before since now you can
match a larger selection of text yet only use a small portion of it for
the actual "end must match begin" portion.

* (pgsql) add test for $$ quoting existing behavior

- even if that existing behavior is questionable
- the ending span should really close before the $$, not after

Fixing this would involve delving into the sublanguage behavior and I'm
not sure we have time to tackle that right this moment.

* (chore) pgsql uses END_SAME_AS_BEGIN mode/rule now also

* (docs) rename to `mode_reference`; docs for callbacks

- I can never find this file because it's name didn't fully match.
- rename callbacks to `on:begin` and `on:end`

* prevented setter keyword conflicting with setTimeout|setInterval and highlighted them (highlightjs#2514) (highlightjs#2515)

* fix(javascript) prevent setter keyword 'set' conflicting with setTimeout|setInterval (highlightjs#2514)
* enh(javascript) setTimeout|setInterval now highlighted (highlightjs#2514)
* enh (javascript) clearInterval and clearTimeout now highlighted
* add keywords to TypeScript also

* (docs) add TLDR instructions for building and testing

* (dev) improve developer tool UI

* (parser) Build common EMCAscript foundation

Builds a common keyword foundation for any grammar that is
building on top of JavaScript:

- LiveScript
- CoffeeScript
- TypeScript

Also uses this common foundation for JS itself.

* (parser) Adds SHEBANG mode

* (yaml) Add support for inline sequences and mappings (highlightjs#2513)

* Use containers to match inline sequences and mappings
* Add string type for inside inline elements
* Handle nested inline sequences and mappings
* Disallow all braces brackets and commas from strings inside inline mappings or sequences
* clean up implementation
* feed the linter

Co-authored-by: Josh Goebel <me@joshgoebel.com>

* [enh] Add `OPTIMIZE:` and `HACK:` to comment doctags

* (build) browser build is CommonJS and IIFE, no more AMD (highlightjs#2511)

* (build) browser build is CommonJS and IIFE (global) now
* (build) dropping support for AMD, which we never truly supported
  properly in the first place
* (build) add test to make sure browser build works as commonJS module

  Resolves highlightjs#2505

* fix(parser) Fix freezing issue with illegal 0 width matches (highlightjs#2524)

* fix[parser] add edge case handle for illegal 0 width matches
* add last ditch catch all that tries to detect other uncaught freezes

* (docs) added unicorn-rails-log as an 3rd-party language (highlightjs#2528)

- (docs) Add syntax highlighting for Rails Unicorn logging to supported languages.

* (docs) fix supported languages link: it moved again! (highlightjs#2533)

* fix(ts/js) use identifier to match potential keywords (highlightjs#2519)

- (parser) Adds `keywords.$pattern` key to grammar definitions
- `lexemes` is now deprecated in favor of `keywords.$pattern` key
- enh(typescript) use identifier to match potential keywords, preventing false positives 
- enh(javascript) use identifier to match potential keywords, preventing false positives

* fix(javascript) fix regex inside parens after a non-regex (highlightjs#2531)

* make the object attr container smarter
* deal with multi-line comments also
* comments in any order, spanning multiple lines

Essentially makes the object attr container much more sensitive by allowing it to look-ahead thru comments to find object keys - and therefore prevent them from being incorrectly matched by the "value container" rule.

* (parser) Add hljs.registerAlias() public API (highlightjs#2540)

* Add hljs.registerAlias(alias, languageName) public API
* Add .registerAlias() test

* enh(cpp) add `pair`, `make_pair`, `priority_queue` as built-ins (highlightjs#2538)

* (fix) `fixMarkup` would rarely destroy markup when `useBR` was enabled (highlightjs#2532)

* enh(cpp) Recognize `priority_queue`, `pair` as containers (highlightjs#2541)

* chore: rename `registerAlias` to `registerAliases`

Plural form is clearly better as it's not surprising to the reader
to see it being passed an array - where as the singular form might
have been.  Meanwhile it's also easy to assume that it also supports
arrays of any size - including an array with a singular alias.

The fact that it can magically accept a string as the first argument
might not be obvious, but we document it and even if one didn't know
this they could still use the array form of the API without any issue
by passing a one item array.

* (swift) @objcMembers not completely highlighted (highlightjs#2543)

* Fixed @objcMembers in Swift

Would match `@objc` first, and the `Members` part would be unhighlighted

* Update CHANGES.md

* Update swift.js

* (docs) add OCL to list of supported languages (highlightjs#2547)

* (docs) Add Svelte to list of supported languages (highlightjs#2549)

* enh(dart) Add `late` and `required` keywords, and `Never` built-in type (Dart 2.9) (highlightjs#2551)

* Add new Dart 2.9 keywords for Null Safety language feature

* enh(erlang) add support for underscore separators in numeric literals (highlightjs#2554)

* (erlang) add support for underscore separators in numeric literals
* (erlang) add tests

* (docs) add Jolie to Supported Languages (highlightjs#2556)

* (parser/docs) Add jsdoc annotations and TypeScript type file (highlightjs#2517)

Adds JSDoc annotations and a .tsconfig that allows TypeScript to be run in it's "allowJS" mode and apply type and sanity checking to JavaScript code also. See Type Checking JavaScript Files.

I've been using TypeScript a lot lately and finding it very beneficial and wanted to get those same benefits here but without converting the whole project to TypeScript. It was rough at the beginning but now that this is finished I think it's about 80%-90% of the benefits without any of the TS compilation pipeline. The big difference in being JSDoc for adding typing information vs inline types with TypeScript.

Should be super helpful for maintainers using an editor with tight TypeScript integration and the improved docs/comments should help everyone else.

- Adds types/index.d.ts to NPM build (should be useful for TypeScript peeps)
- Improves documentation of many functions
- Adds JSDoc annotations to almost all functions
- Adds JSDoc type annotations to variables that can't be inferred
- Refactors a few smaller things to allow the TypeScript compiler to better infer what 
   is happening (and usually also made the code clearer)

* (parser) highlightBlock result key `re` => `relevance` (highlightjs#2553)

* enh(handlebars) Support for sub-expressions, path-expressions, hashes, block-parameters and literals (highlightjs#2344)

- `htmlbars` grammar is now deprecated. Use `handlebars` instead.

A stub is included so that anyone literally referencing the old `htmlbars` file (say manually requiring it in Node.js, etc) is still covered, but everyone should transition to `handlebars` now.

* fix(typescript) Add missing `readonly` keyword (highlightjs#2562)

* (docs) Mention `c` is a possible class for C (highlightjs#2577)

* fix(groovy) strings are not allowed inside ternary clauses (highlightjs#2565)

* fix(groovy) strings are not allowed inside ternary clauses
* whitespace can also include tabs

* Update @typescript-eslint/parser to the latest version 🚀 (highlightjs#2575)

* chore(package): update @typescript-eslint/parser to version 3.0.0
* chore(package): update lockfile package-lock.json

Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
Co-authored-by: Josh Goebel <me@joshgoebel.com>

* Update @typescript-eslint/eslint-plugin to the latest version 🚀 (highlightjs#2576)

* chore(package): update @typescript-eslint/eslint-plugin to version 3.0.0
* chore(package): update lockfile package-lock.json

Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
Co-authored-by: Josh Goebel <me@joshgoebel.com>

* (parser) properly escape ' and " in HTML output (highlightjs#2564)

* escape quotes also in final HTML output
* [style] update test coding style
* update markup tests with new escaping

This shouldn't be a security issue -- we've always escaped double quotes inside of HTML attribute values (where they could be used to break out of context) - and we've always used double quotes for enclosing attribute values. 

This just goes all the way and now properly escapes quotes everywhere.  Better safe than sorry.

* (docs) add changelog entry for last PR

* add nnfx theme (highlightjs#2571)

* (themes) Add new lioshi theme (highlightjs#2581)

* Added Cisco Command Line to SUPPORTED_LANGUAGES.md (highlightjs#2583)

* (themes) add `nnfx-dark` theme (highlightjs#2584)

* enh(protobuf) Support multiline comments  (highlightjs#2597)

* enh(java) added support for hexadecimal floating point literals (highlightjs#2509)

- Added support for many additional types of floating point literals
- Added related tests

There still may be a few gaps, but this is a pretty large improvement.

Co-authored-by: Josh Goebel <me@joshgoebel.com>

* (chore) Update issue templates (highlightjs#2574)

Co-authored-by: Vladimir Jimenez <allejo@me.com>

* enh(toml)(ini) Improve parsing of complex keys (highlightjs#2595)

Fixes: highlightjs#2594

* (chore) add `.js` extension to import statements (highlightjs#2601)

Adds file extensions to all import specifiers in ./src/ files.  This is useful to run the files straight from source with a web browser , Node.js ESM or Deno.

- Also add eslint rules regarding extensions for imports

* enh(dart) highlight built-in nullable types (highlightjs#2598)

* Dart: allow built-in nullable types with trailing ? to be highlighted

* enh(csharp) highlight generics in more cases (highlightjs#2599)

* (chore) fix tiny style issues, add linting npm task

- fixes tiny style issues
- adds `npm run lint` for linting the main library source
  (not languages which are still much messier)

* (chore) bump dev dependencies

* (chore) upgrade some dev stuff to newer versions

* bump v10.1.0

* (chore) bump copyright

* (chore) more import below metadata comment

Co-authored-by: M. Mert Yıldıran <mehmetmertyildiran@gmail.com>
Co-authored-by: Josh Goebel <me@joshgoebel.com>
Co-authored-by: Hugo Leblanc <dullin@hololink.org>
Co-authored-by: Peter Massey-Plantinga <plantinga.peter@gmail.com>
Co-authored-by: David Benjamin <davidben@google.com>
Co-authored-by: Vania Kucher <dev.kucher@gmail.com>
Co-authored-by: SweetPPro <sweetppro@users.noreply.github.com>
Co-authored-by: Alexandre ZANNI <16578570+noraj@users.noreply.github.com>
Co-authored-by: Taufik Nurrohman <t.nurrohman77@gmail.com>
Co-authored-by: Lin <50829219+Linhk1606@users.noreply.github.com>
Co-authored-by: nicked <nicked@gmail.com>
Co-authored-by: Nicolas Homble <nhomble@terpmail.umd.edu>
Co-authored-by: Ryandi Tjia <ryandi.tjia@me.com>
Co-authored-by: Sam Rawlins <srawlins@google.com>
Co-authored-by: Sergey Prokhorov <seriy.pr@gmail.com>
Co-authored-by: Brian Alberg <brian@alberg.org>
Co-authored-by: Nils Knappmeier <github@knappi.org>
Co-authored-by: Martin <7252614+Lhoerion@users.noreply.github.com>
Co-authored-by: Derek Lewis <DerekNonGeneric@inf.is>
Co-authored-by: greenkeeper[bot] <23040076+greenkeeper[bot]@users.noreply.github.com>
Co-authored-by: Jim Mason <jmason@ibinx.com>
Co-authored-by: lioshi <lionel.fenneteau@gmail.com>
Co-authored-by: BMatheas <65114274+BMatheas@users.noreply.github.com>
Co-authored-by: Pavel Evstigneev <pavel.evst@gmail.com>
Co-authored-by: Vladimir Jimenez <allejo@me.com>
Co-authored-by: Antoine du Hamel <duhamelantoine1995@gmail.com>
Co-authored-by: TupikovVladimir <vladimir.tupikov@devexpress.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug help welcome Could use help from community package/build Issues relating to npm or packaging
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants