lib: add parser.stripTypeScriptTypes

[marco-ippolito]

Fixes: #54300

[nodejs-github-bot]

Review requested:

• @nodejs/loaders
• @nodejs/vm

[joyeecheung]

I think it makes more sense for it to be just in its own API as a function, which can be used to strip the type before the text is passed into any of the vm.Script/vm.SourceTextModule/vm.compileFunction APIs. That'll also be useful for those who want to transform the text but not compile it at all. The transform option being ignored without the flag could be somewhat surprising, especially paired with cachedData which only has a length check, so it could lead to crashes when V8 tries to reparse the untransformed source for error reporting.

[devsnek]

there's also #54250

[marco-ippolito]

there's also #54250

Unfortunately it seems to have been stalled for a while.
Anyways good to review, I'm just not sure whether to be strict and throw when mode is strip-only and sourceMap is passed, otherwise will be ignored and could be counter-intuitive

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 88.41%. Comparing base (80b56bb) to head (ede9ffe).
Report is 6 commits behind head on main.

Additional details and impacted files

@@            Coverage Diff             @@
##             main   #55282      +/-   ##
==========================================
- Coverage   88.41%   88.41%   -0.01%     
==========================================
  Files         652      654       +2     
  Lines      186856   186939      +83     
  Branches    36058    36072      +14     
==========================================
+ Hits       165210   165275      +65     
- Misses      14901    14902       +1     
- Partials     6745     6762      +17     

Files with missing lines	Coverage Δ
lib/internal/bootstrap/realm.js	96.85% <100.00%> (+<0.01%)	⬆️
lib/internal/main/eval_string.js	80.00% <100.00%> (ø)
lib/internal/modules/cjs/loader.js	97.38% <100.00%> (-0.06%)	⬇️
lib/internal/modules/esm/get_format.js	89.32% <100.00%> (+0.04%)	⬆️
lib/internal/modules/esm/translators.js	93.09% <100.00%> (ø)
lib/internal/modules/helpers.js	98.61% <100.00%> (-0.39%)	⬇️
lib/internal/parser/typescript.js	100.00% <100.00%> (ø)
lib/parser.js	100.00% <100.00%> (ø)
src/node_builtins.cc	78.48% <100.00%> (+0.05%)	⬆️

... and 35 files with indirect coverage changes

[legendecas]

I think this could be benefited from a dedicated module parser (name bikeshed welcome), instead of vm since the updated PR doesn't involve with any code evaluation. This module could provide additional helpers to address similar needs on manipulating JS source codes.

[joyeecheung]

Maybe putting it on module also makes sense? Or module.typescript if we can foresee adding other typescript-related utilities in the future

[marco-ippolito]

I think this could be benefited from a dedicated module parser (name bikeshed welcome), instead of vm since the updated PR doesn't involve with any code evaluation. This module could provide additional helpers to address similar needs on manipulating JS source codes.

I'm ok with a new module, I think parser is ok, I'd like to hear more opinions about it
I wouldnt call it typescript and leave it more generic, maybe someone wants to add ast manipulation or bundling etc... could be the right place

[marco-ippolito]

If we decide to ship it I'll drop the vm commits
Pinging TSC as adding a new module seems like a big deal @nodejs/tsc

[joyeecheung]

If this needs to be a new module, then it should be added to

node/lib/internal/bootstrap/realm.js

Line 130 in b4e8f1b

const schemelessBlockList = new SafeSet([

to block require('parser') without the node: prefix, otherwise it breaks https://www.npmjs.com/package/parser or anyone creating an alias of parser in node_modules.

[anonrig]

I see there is some disagreement about where this feature should go.

After playing around a bit I think creating a new module is the right thing.

The reason is:

• It should not live in vm since it doesnt run code

• It should not live in module since its not really related to a particular module system. Its unrelated to --experimental-strip-types since it does not depend on the flag

@marco-ippolito do you see a different parser added into this new module soon? I don't think we should add a new module just for a single function. Why don't we put it under util?

[marco-ippolito]

@anonrig I think there is the possibility of adding more functions to manipulate code. But imho this new feature does not belong in any of the current modules

[legendecas]

Certainly node:util can be a nest for any functions. Requiring the node: prefix, a new core module would help categorize new functionality more precisely without shadowing ecosystem packages.

I think the scope of the new function is clear that it provides new functionality of parsing and manipulating JS source codes, without evaluating them.

[anonrig]

@marco-ippolito We have parseEnv method in node:util. So this means we will add that function to node:parser as well?

[marco-ippolito]

@marco-ippolito We have parseEnv file in node:util. So this means we will add that function to node:parser as well?

Yes, it manipulates source code without evaluating it (even though its not js)

[github-actions]

Failed to start CI

   ⚠  Something was pushed to the Pull Request branch since the last approving review.
   ✘  Refusing to run CI on potentially unsafe PR

https://github.com/nodejs/node/actions/runs/11327838941

[anonrig]

I'm sorry for doing this, but I think we shouldn't introduce a new module just for a single method. This should live in node:util with similar functions like parseEnv.

[marco-ippolito]

@anonrig I feel like I motivated the decision in previous comment, that function that manipulate source code without evaluating should be moved to this module, like parseEnv, not the opposite. Everything can go in util.
Pinging @nodejs/tsc as I dont agree this should go in util.

[mcollina]

@marco-ippolito I think this is a textbook case for calling a vote.

I dislike the use of name node:parser, something like node:code_transformations would fit better or even as an utility in node:module.

util is fine, as long as the dependency is loaded dynamically.