TypeScript and ES6+ support using esbuild. #3738
Conversation
With the introduction of the "enhanced" compatibility mode, the test source code is transformed using esbuild instead of Babel. Source files with the extension ".ts" are loaded by esbuild's TypeScript loader, which results in partial TypeScript support. This esbuild removes exactly the type information, but does not provide type safety. Source files other than ".ts" are loaded by esbuild's JavaScript loader, which results in the support of a more modern JavaScript dialect than goja.
…rors. Running the tc39 tests also in "enhanced" (esbuild) compatibility mode. Previously, the test wrote the JSON format file to be saved to the standard output, which had to be manually cleaned from the other test output. This solution is difficult to apply in the case of one or more compatibility modes, so it has been changed to the usual golden file pattern. The reference breaking_test_errors-extended.json and breaking_test_errors-enhanced.json files can be updated using the go test -update command.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #3738 +/- ##
==========================================
+ Coverage 70.78% 70.83% +0.05%
==========================================
Files 287 288 +1
Lines 21151 21186 +35
==========================================
+ Hits 14971 15008 +37
+ Misses 5217 5215 -2
Partials 963 963
Flags with carried forward coverage won't be shown. Click here to find out more. ☔ View full report in Codecov by Sentry. |
szkiba
requested review from
codebien and
olegbespalov
and removed request for
a team
There was a problem hiding this comment.
Source files with the extension ".ts" are loaded by esbuild's TypeScript loader, which results in partial TypeScript support. This esbuild removes exactly the type information, but does not provide type safety.
@szkiba can you expand on this topic? Isn't the main advantage of having TypeScript? Does it mean we are delegating it to another tool and k6 makes the assumption to receive a valid script?
With the introduction of the "enhanced" compatibility mode
Can you explain the reason behind the enhanced term, please? Isn't better for clarity to use something related to typescript or esbuild?
Last point, I see we are not running the js/tc39 suite. I expect it is the first requirement for being able to merge this pull request. Can you please make the changes for running it with the new mode? It is probably the fastest way to catch any potential issue without manually checking all the bits.
|
Hi @codebien , thank you for your review.
Sorry if I was unclear: we do not delegate the loading to a tool, but to the esbuild library. Within the esbuild library, there are so-called loaders for each type of content. The quoted sentence indicates that files with the .ts extension will be treated as TypeScript files, in the case of other file extensions, the input will be assumed to be JavaScript.
The name of the mode is not
I think the tc39 test is running, I modified the tc39_test.go file: |
If this is the case, what is missing for attempting a Babel replacement? So, instead of creating a new mode, we do an expansion of the extended mode.
Oh, thanks. I missed it. |
That's exactly what I think, esbuild will replace babel (one day). I created a new compatibility mode so that esbuild can be completely disabled (and disabled by default). With such a major, potential incompatibility change, I think this is important. Later, esbuild can take over the role of babel and then the two compatibility modes (extended and enhanced) can mean the same thing. |
|
If this is the case, should we go with something like |
How about |
|
@szkiba I tried running a tests in grafana-api-test library but I get this error: |
This is a consequence of the fact that esbuild does not run as a bundler, but transforms per module. The module resolving (require function) is implemented by the k6 runtime. Specifying the file extension is mandatory in this implementation. |
But the convention is not to include the extension, right? |
What?
With the introduction of the "enhanced" compatibility mode, the test source code is transformed using esbuild instead of Babel.
Why?
Source files with the extension ".ts" are loaded by esbuild's TypeScript loader, which results in partial TypeScript support. This esbuild removes exactly the type information, but does not provide type safety.
Source files other than ".ts" are loaded by esbuild's JavaScript loader, which results in the support of a more modern JavaScript dialect than goja.
Checklist
make lint) and all checks pass.make tests) and all tests pass.Related PR(s)/Issue(s)
#3703
Closes #3703