Transition to ES6? #76
Comments
|
updated: The motivation for sticking with ES5 is discussed in PR #107. That said, I am thinking it would be nice to look for a better way to support users who need ES5. This would definitely be a breaking change. original response: Definitely an interesting idea. I think we could definitely use some modernization, using "Standard JS" or semistandard, for example (see #29). In terms of using ES6 import and export statements, which may overlap with #75, it would be a breaking change and maybe require setting module type in package.json, looks not well standardized, or add a pre-publish build step, which I would like to avoid. I would also downvote switching to TS, since it would both add another build step and add a possible barrier of entry. It is possible to use TypeScript to do type checking with JSDoc type comments, which I would favor looking into. |
|
Keeping it simple is the best way to go, so no TS makes sense. Given the minimum target NodeJS version is 10, I imagine the changes could be done in an evolutionary way, before dealing with anything truly breaking. There is already a lot that can be done, assuming that as minimal environment? Simple things like moving from var to const/let could be easy wins. Since there are tests, this will also help identify anything that breaks functionality? |
|
Thx for raising the topic. I think adding an a TS check on the js code based on JSDoc comments might already reveal many "issues" (also need to be treated with care, any change could be breaking), and it's something I have some experience with. |
|
Sure keeping it simple is important. However, I would argue that it should be simpler to work with ES6 than with legacy JavaScript.
That is true, but unfortunately the TS type syntax support in JsDoc is somewhat limited. |
|
We use xmldom (at any rate, the dom.js module) in Saxon-JS. We probably forked our copy 3 or 4 years ago, but kept changes to a minimum. We've made a few very small changes to fix minor bugs and to make it compile more nicely under Closure. We've been moving the rest of our code to ES6 and I'm very tempted to do the same with dom.js; it's not clear that we'd lose much by forking. Although there's a fair trickle of activity, there don't seem to be any "must have" changes. |
|
Even though it's a bit off topic in this issue: As to the "moving to ES6", I still think we will need to talk about many things before we can even get started. Since I'm not sure what environments we would break by no longer supporting older browsers. I don't have any issues with typescript and I think we will massively benefit from it even if we just run it over the current code base as part of development/CI. I also think t would also really speed up development, but I think it's a long path to go from where we are right now. |
|
@michaelhkay I would also be happy with contribution of the bug fixes. Maintaining a fork should ideally be a last resort. At this point we would be pretty reluctant to switch to ES6 since this would break in some ES5 environments, as discussed in PR #107. For type checking, I would favor using JSDoc comments rather than switching to TypeScript. I think this would be similar to using Closure. I have contributed some changes to do this in Prettier, and there is a nice writeup here: https://fettblog.eu/typescript-jsdoc-superpowers/ |
|
I'll see if I can cherry-pick our changes and submit those that are relevant as PRs, especially if someone else can volunteer to run all the tests (we know the code works within its Saxon-JS environment, but we also know that we don't use all paths, for example we never do in-situ update). Some of the changes probably wouldn't survive review, for example there's discussion here about making NodeList iterable which discusses lots of pros and cons that we weren't bothered with, we just went ahead and did it, probably badly, but well enough for our purposes.
We don't use xmldom for parsing or serialization, by the way. We interfaced the sax2 parser to do the tree building, which we found to be more conformant (though still far from perfect), and we wrote our own serializer with all the bells and whistles defined in the XSLT specification. A good conformant XML parser with DTD and entity handling is something that's sorely missing in the Node.js world, as far as I can see. But I would certainly like to be able to use xmldom "off-the-shelf" rather than using our own home-brew variant, to ensure that Saxon-JS can always accept DOM trees produced by other applications.
Michael Kay
Saxonica
… On 2 Oct 2020, at 00:46, Christian Bewernitz ***@***.***> wrote:
Even though it's a bit off topic in this issue:
@michaelhkay <https://github.com/michaelhkay> I think we would be very happy to integrate your bug fixes into this code base. Are you able to file one or more PRs?
If not can you point us to the fork you are talking about, so we can see if we are able to cherry pick?
As to the "moving to ES6", I still think we will need to talk about many things before we can even get started. Since I'm not sure what environments we would break by no longer supporting older browsers.
And if we want to go there and support them we will need some kind of transpilation.
But I'm not so confident that our current test suite would really prevent us from breaking things...
I don't have any issues with typescript and I think we will massively benefit from it even if we just run it over the current code base as part of development/CI. I also think t would also really speed up development, but I think it's a long path to go from where we are right now.
(More contributors of course always help with that.)
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#76 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AASIQISZGIZ75TG7MTJ4YJTSIUIEXANCNFSM4OMNWSGQ>.
|
|
@karfau What is the status of this? |
|
I've done a quick comparison of our version of dom.js against the current master. In fact it seems we did very little other than add some diagnostic code. The places we did a few bug fixes were in sax.js, which we use for parsing. The master code has evolved a great deal since we took our snapshot, but we haven't got a strong reason to merge the updates. Longer term we're more likely to cut our own tree model separate from DOM; our experience on the Java side is that you can get significant benefits by using an immutable tree that's more closely integrated with the XPath engine. |
|
Not any progress other then discussions. One main reason for this not happening is the lack of resources. If there would ever be enough resources for such a rewrite I would most likely vote for moving to typescript and add a build step to support all the environments people have asked for. |
|
Just to mention it here, since I think it's quite relevant: Also other runtimes like Deno and Bun are becoming more popular/relevant, and some of them already bring their own spec compliant implementation(s). |
I am curious whether there is any interest to transition the library to use ES6 coding or even TS?
I did look to see if there was a previous ticket on this, but did not see any. Also, given the stability of library I can appreciate that it may not be desirable, though figured I'd file the ticket just so it is asked.
The text was updated successfully, but these errors were encountered: