Skip transpilation of CommonJS modules#8

make-github-pseudonymous-again · 2021-12-22T12:58:14Z

I am nitpicking here but other formats include builtin, json, and wasm (see https://nodejs.org/api/esm.html#loadurl-context-defaultload). The logic makes sense. The comment could be improved.

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
Suggested change
// Skip transpilation of CommonJS modules.
// These modules are already preprocessed by Node.js,
// so we cannot parse the non-standard syntaxes like JSX and TypeScript.
// Their transpilation is better handled separately by @babel/register or @babel/node.
if(format!=="module"){
return{ source, format };
}
if(format!=="module"&&format!=="commonjs"){
return{ source, format };
}

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
Looking forward what you say makes sense. It may be that one day node loader handles the source key for {format: 'commonjs'}. But insisting on commonjs being transpiled now makes little sense. As far as I understand, with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null. Babel gracefully handles null by producing null with little overhead. If one day source is non-null and has meaning for format = 'commonjs' suddenly this loader will start transpiling CJS input without warning. Not sure if this is a real stability threat but I feel like it is a bad idea to leave this open for this code to be general just in the case of "if ...".
I agree this behavior could be configurable by the user of node-loader-babel. I just think the default should be to only process 'module' input.
Note that without this PR, when input format is commonjs, input and output source are null and output format is module which is the reason of the bug described in #7.

As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?

In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?
Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
https://babeljs.io/docs/en/babel-preset-env#modules
I just think the default should be to only process 'module' input.
I can see how that would help solve the immediate problem, but don't think it's actually the proper behavior for node-loader-babel as a whole. If we can get babel to output the correct module format, there's no reason to avoid compilation of CJS files.
with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null
Why would source be null? Does nodejs' default loader not provide commonjs source as a string? If so, then perhaps your suggestion of disabling would make more sense. But I thought that nodejs would give us the source as a string.

Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
OK. I cannot find how to do this in the REPL, maybe it is not possible.

internettrans · 2021-12-27T21:16:26Z

Which bug in transform-modules-commonjs you're referring to?
I don't think we ever need to forcibly change the module format - see my comment above about how I don't think babel will change module format unless explicitly told to do so via plugin, which is something controlled via babel config.

make-github-pseudonymous-again · 2021-12-22T13:00:49Z

Does transformed.sourceType really reflect the output format? Perhaps it makes more sense to assume output is module or fail if it is not given source is not applicable for format: "commonjs" (see https://nodejs.org/api/esm.html#loadurl-context-defaultload).

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?
I do not know, I am just confused as to whether sourceType corresponds to the input sourceType or the output sourceType, since source carries an input meaning to me. Experimental node loader uses the source keyword for both "input" and "output" but the babel equivalent is transformed.code. I could not find the Babel documentation that explains what transformed.sourceType means. If you can find it please share.

make-github-pseudonymous-again · 2021-12-22T13:01:41Z

This is neat!

make-github-pseudonymous-again · 2021-12-22T12:58:14Z

I am nitpicking here but other formats include builtin, json, and wasm (see https://nodejs.org/api/esm.html#loadurl-context-defaultload). The logic makes sense. The comment could be improved.

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
Suggested change
// Skip transpilation of CommonJS modules.
// These modules are already preprocessed by Node.js,
// so we cannot parse the non-standard syntaxes like JSX and TypeScript.
// Their transpilation is better handled separately by @babel/register or @babel/node.
if(format!=="module"){
return{ source, format };
}
if(format!=="module"&&format!=="commonjs"){
return{ source, format };
}

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
Looking forward what you say makes sense. It may be that one day node loader handles the source key for {format: 'commonjs'}. But insisting on commonjs being transpiled now makes little sense. As far as I understand, with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null. Babel gracefully handles null by producing null with little overhead. If one day source is non-null and has meaning for format = 'commonjs' suddenly this loader will start transpiling CJS input without warning. Not sure if this is a real stability threat but I feel like it is a bad idea to leave this open for this code to be general just in the case of "if ...".
I agree this behavior could be configurable by the user of node-loader-babel. I just think the default should be to only process 'module' input.
Note that without this PR, when input format is commonjs, input and output source are null and output format is module which is the reason of the bug described in #7.

As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?

In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?
Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
https://babeljs.io/docs/en/babel-preset-env#modules
I just think the default should be to only process 'module' input.
I can see how that would help solve the immediate problem, but don't think it's actually the proper behavior for node-loader-babel as a whole. If we can get babel to output the correct module format, there's no reason to avoid compilation of CJS files.
with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null
Why would source be null? Does nodejs' default loader not provide commonjs source as a string? If so, then perhaps your suggestion of disabling would make more sense. But I thought that nodejs would give us the source as a string.

Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
OK. I cannot find how to do this in the REPL, maybe it is not possible.

internettrans · 2021-12-27T21:16:26Z

Which bug in transform-modules-commonjs you're referring to?
I don't think we ever need to forcibly change the module format - see my comment above about how I don't think babel will change module format unless explicitly told to do so via plugin, which is something controlled via babel config.

make-github-pseudonymous-again · 2021-12-22T13:00:49Z

Does transformed.sourceType really reflect the output format? Perhaps it makes more sense to assume output is module or fail if it is not given source is not applicable for format: "commonjs" (see https://nodejs.org/api/esm.html#loadurl-context-defaultload).

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?
I do not know, I am just confused as to whether sourceType corresponds to the input sourceType or the output sourceType, since source carries an input meaning to me. Experimental node loader uses the source keyword for both "input" and "output" but the babel equivalent is transformed.code. I could not find the Babel documentation that explains what transformed.sourceType means. If you can find it please share.

make-github-pseudonymous-again · 2021-12-22T13:01:41Z

This is neat!

make-github-pseudonymous-again · 2021-12-22T12:58:14Z

I am nitpicking here but other formats include builtin, json, and wasm (see https://nodejs.org/api/esm.html#loadurl-context-defaultload). The logic makes sense. The comment could be improved.

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
Suggested change
// Skip transpilation of CommonJS modules.
// These modules are already preprocessed by Node.js,
// so we cannot parse the non-standard syntaxes like JSX and TypeScript.
// Their transpilation is better handled separately by @babel/register or @babel/node.
if(format!=="module"){
return{ source, format };
}
if(format!=="module"&&format!=="commonjs"){
return{ source, format };
}

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
Looking forward what you say makes sense. It may be that one day node loader handles the source key for {format: 'commonjs'}. But insisting on commonjs being transpiled now makes little sense. As far as I understand, with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null. Babel gracefully handles null by producing null with little overhead. If one day source is non-null and has meaning for format = 'commonjs' suddenly this loader will start transpiling CJS input without warning. Not sure if this is a real stability threat but I feel like it is a bad idea to leave this open for this code to be general just in the case of "if ...".
I agree this behavior could be configurable by the user of node-loader-babel. I just think the default should be to only process 'module' input.
Note that without this PR, when input format is commonjs, input and output source are null and output format is module which is the reason of the bug described in #7.

As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?

In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?
Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
https://babeljs.io/docs/en/babel-preset-env#modules
I just think the default should be to only process 'module' input.
I can see how that would help solve the immediate problem, but don't think it's actually the proper behavior for node-loader-babel as a whole. If we can get babel to output the correct module format, there's no reason to avoid compilation of CJS files.
with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null
Why would source be null? Does nodejs' default loader not provide commonjs source as a string? If so, then perhaps your suggestion of disabling would make more sense. But I thought that nodejs would give us the source as a string.

Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
OK. I cannot find how to do this in the REPL, maybe it is not possible.

internettrans · 2021-12-27T21:16:26Z

Which bug in transform-modules-commonjs you're referring to?
I don't think we ever need to forcibly change the module format - see my comment above about how I don't think babel will change module format unless explicitly told to do so via plugin, which is something controlled via babel config.

make-github-pseudonymous-again · 2021-12-22T13:00:49Z

Does transformed.sourceType really reflect the output format? Perhaps it makes more sense to assume output is module or fail if it is not given source is not applicable for format: "commonjs" (see https://nodejs.org/api/esm.html#loadurl-context-defaultload).

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?
I do not know, I am just confused as to whether sourceType corresponds to the input sourceType or the output sourceType, since source carries an input meaning to me. Experimental node loader uses the source keyword for both "input" and "output" but the babel equivalent is transformed.code. I could not find the Babel documentation that explains what transformed.sourceType means. If you can find it please share.

make-github-pseudonymous-again · 2021-12-22T13:01:41Z

This is neat!

make-github-pseudonymous-again · 2021-12-22T12:58:14Z

I am nitpicking here but other formats include builtin, json, and wasm (see https://nodejs.org/api/esm.html#loadurl-context-defaultload). The logic makes sense. The comment could be improved.

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
Suggested change
// Skip transpilation of CommonJS modules.
// These modules are already preprocessed by Node.js,
// so we cannot parse the non-standard syntaxes like JSX and TypeScript.
// Their transpilation is better handled separately by @babel/register or @babel/node.
if(format!=="module"){
return{ source, format };
}
if(format!=="module"&&format!=="commonjs"){
return{ source, format };
}

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
Looking forward what you say makes sense. It may be that one day node loader handles the source key for {format: 'commonjs'}. But insisting on commonjs being transpiled now makes little sense. As far as I understand, with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null. Babel gracefully handles null by producing null with little overhead. If one day source is non-null and has meaning for format = 'commonjs' suddenly this loader will start transpiling CJS input without warning. Not sure if this is a real stability threat but I feel like it is a bad idea to leave this open for this code to be general just in the case of "if ...".
I agree this behavior could be configurable by the user of node-loader-babel. I just think the default should be to only process 'module' input.
Note that without this PR, when input format is commonjs, input and output source are null and output format is module which is the reason of the bug described in #7.

As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?

In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?
Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
https://babeljs.io/docs/en/babel-preset-env#modules
I just think the default should be to only process 'module' input.
I can see how that would help solve the immediate problem, but don't think it's actually the proper behavior for node-loader-babel as a whole. If we can get babel to output the correct module format, there's no reason to avoid compilation of CJS files.
with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null
Why would source be null? Does nodejs' default loader not provide commonjs source as a string? If so, then perhaps your suggestion of disabling would make more sense. But I thought that nodejs would give us the source as a string.

Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
OK. I cannot find how to do this in the REPL, maybe it is not possible.

internettrans · 2021-12-27T21:16:26Z

Which bug in transform-modules-commonjs you're referring to?
I don't think we ever need to forcibly change the module format - see my comment above about how I don't think babel will change module format unless explicitly told to do so via plugin, which is something controlled via babel config.

make-github-pseudonymous-again · 2021-12-22T13:00:49Z

Does transformed.sourceType really reflect the output format? Perhaps it makes more sense to assume output is module or fail if it is not given source is not applicable for format: "commonjs" (see https://nodejs.org/api/esm.html#loadurl-context-defaultload).

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?
I do not know, I am just confused as to whether sourceType corresponds to the input sourceType or the output sourceType, since source carries an input meaning to me. Experimental node loader uses the source keyword for both "input" and "output" but the babel equivalent is transformed.code. I could not find the Babel documentation that explains what transformed.sourceType means. If you can find it please share.

make-github-pseudonymous-again · 2021-12-22T13:01:41Z

This is neat!

make-github-pseudonymous-again · 2021-12-22T12:58:14Z

I am nitpicking here but other formats include builtin, json, and wasm (see https://nodejs.org/api/esm.html#loadurl-context-defaultload). The logic makes sense. The comment could be improved.

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
Suggested change
// Skip transpilation of CommonJS modules.
// These modules are already preprocessed by Node.js,
// so we cannot parse the non-standard syntaxes like JSX and TypeScript.
// Their transpilation is better handled separately by @babel/register or @babel/node.
if(format!=="module"){
return{ source, format };
}
if(format!=="module"&&format!=="commonjs"){
return{ source, format };
}

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
Looking forward what you say makes sense. It may be that one day node loader handles the source key for {format: 'commonjs'}. But insisting on commonjs being transpiled now makes little sense. As far as I understand, with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null. Babel gracefully handles null by producing null with little overhead. If one day source is non-null and has meaning for format = 'commonjs' suddenly this loader will start transpiling CJS input without warning. Not sure if this is a real stability threat but I feel like it is a bad idea to leave this open for this code to be general just in the case of "if ...".
I agree this behavior could be configurable by the user of node-loader-babel. I just think the default should be to only process 'module' input.
Note that without this PR, when input format is commonjs, input and output source are null and output format is module which is the reason of the bug described in #7.

As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?

In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?
Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
https://babeljs.io/docs/en/babel-preset-env#modules
I just think the default should be to only process 'module' input.
I can see how that would help solve the immediate problem, but don't think it's actually the proper behavior for node-loader-babel as a whole. If we can get babel to output the correct module format, there's no reason to avoid compilation of CJS files.
with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null
Why would source be null? Does nodejs' default loader not provide commonjs source as a string? If so, then perhaps your suggestion of disabling would make more sense. But I thought that nodejs would give us the source as a string.

Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
OK. I cannot find how to do this in the REPL, maybe it is not possible.

internettrans · 2021-12-27T21:16:26Z

Which bug in transform-modules-commonjs you're referring to?
I don't think we ever need to forcibly change the module format - see my comment above about how I don't think babel will change module format unless explicitly told to do so via plugin, which is something controlled via babel config.

make-github-pseudonymous-again · 2021-12-22T13:00:49Z

Does transformed.sourceType really reflect the output format? Perhaps it makes more sense to assume output is module or fail if it is not given source is not applicable for format: "commonjs" (see https://nodejs.org/api/esm.html#loadurl-context-defaultload).

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?
I do not know, I am just confused as to whether sourceType corresponds to the input sourceType or the output sourceType, since source carries an input meaning to me. Experimental node loader uses the source keyword for both "input" and "output" but the babel equivalent is transformed.code. I could not find the Babel documentation that explains what transformed.sourceType means. If you can find it please share.

make-github-pseudonymous-again · 2021-12-22T13:01:41Z

This is neat!

make-github-pseudonymous-again · 2021-12-22T12:58:14Z

I am nitpicking here but other formats include builtin, json, and wasm (see https://nodejs.org/api/esm.html#loadurl-context-defaultload). The logic makes sense. The comment could be improved.

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
Suggested change
// Skip transpilation of CommonJS modules.
// These modules are already preprocessed by Node.js,
// so we cannot parse the non-standard syntaxes like JSX and TypeScript.
// Their transpilation is better handled separately by @babel/register or @babel/node.
if(format!=="module"){
return{ source, format };
}
if(format!=="module"&&format!=="commonjs"){
return{ source, format };
}

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
Looking forward what you say makes sense. It may be that one day node loader handles the source key for {format: 'commonjs'}. But insisting on commonjs being transpiled now makes little sense. As far as I understand, with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null. Babel gracefully handles null by producing null with little overhead. If one day source is non-null and has meaning for format = 'commonjs' suddenly this loader will start transpiling CJS input without warning. Not sure if this is a real stability threat but I feel like it is a bad idea to leave this open for this code to be general just in the case of "if ...".
I agree this behavior could be configurable by the user of node-loader-babel. I just think the default should be to only process 'module' input.
Note that without this PR, when input format is commonjs, input and output source are null and output format is module which is the reason of the bug described in #7.

As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?

In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?
Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
https://babeljs.io/docs/en/babel-preset-env#modules
I just think the default should be to only process 'module' input.
I can see how that would help solve the immediate problem, but don't think it's actually the proper behavior for node-loader-babel as a whole. If we can get babel to output the correct module format, there's no reason to avoid compilation of CJS files.
with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null
Why would source be null? Does nodejs' default loader not provide commonjs source as a string? If so, then perhaps your suggestion of disabling would make more sense. But I thought that nodejs would give us the source as a string.

Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
OK. I cannot find how to do this in the REPL, maybe it is not possible.

internettrans · 2021-12-27T21:16:26Z

Which bug in transform-modules-commonjs you're referring to?
I don't think we ever need to forcibly change the module format - see my comment above about how I don't think babel will change module format unless explicitly told to do so via plugin, which is something controlled via babel config.

make-github-pseudonymous-again · 2021-12-22T13:00:49Z

Does transformed.sourceType really reflect the output format? Perhaps it makes more sense to assume output is module or fail if it is not given source is not applicable for format: "commonjs" (see https://nodejs.org/api/esm.html#loadurl-context-defaultload).

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?
I do not know, I am just confused as to whether sourceType corresponds to the input sourceType or the output sourceType, since source carries an input meaning to me. Experimental node loader uses the source keyword for both "input" and "output" but the babel equivalent is transformed.code. I could not find the Babel documentation that explains what transformed.sourceType means. If you can find it please share.

make-github-pseudonymous-again · 2021-12-22T13:01:41Z

This is neat!

make-github-pseudonymous-again · 2021-12-22T12:58:14Z

I am nitpicking here but other formats include builtin, json, and wasm (see https://nodejs.org/api/esm.html#loadurl-context-defaultload). The logic makes sense. The comment could be improved.

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
Suggested change
// Skip transpilation of CommonJS modules.
// These modules are already preprocessed by Node.js,
// so we cannot parse the non-standard syntaxes like JSX and TypeScript.
// Their transpilation is better handled separately by @babel/register or @babel/node.
if(format!=="module"){
return{ source, format };
}
if(format!=="module"&&format!=="commonjs"){
return{ source, format };
}

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
Looking forward what you say makes sense. It may be that one day node loader handles the source key for {format: 'commonjs'}. But insisting on commonjs being transpiled now makes little sense. As far as I understand, with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null. Babel gracefully handles null by producing null with little overhead. If one day source is non-null and has meaning for format = 'commonjs' suddenly this loader will start transpiling CJS input without warning. Not sure if this is a real stability threat but I feel like it is a bad idea to leave this open for this code to be general just in the case of "if ...".
I agree this behavior could be configurable by the user of node-loader-babel. I just think the default should be to only process 'module' input.
Note that without this PR, when input format is commonjs, input and output source are null and output format is module which is the reason of the bug described in #7.

As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?

In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?
Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
https://babeljs.io/docs/en/babel-preset-env#modules
I just think the default should be to only process 'module' input.
I can see how that would help solve the immediate problem, but don't think it's actually the proper behavior for node-loader-babel as a whole. If we can get babel to output the correct module format, there's no reason to avoid compilation of CJS files.
with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null
Why would source be null? Does nodejs' default loader not provide commonjs source as a string? If so, then perhaps your suggestion of disabling would make more sense. But I thought that nodejs would give us the source as a string.

Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
OK. I cannot find how to do this in the REPL, maybe it is not possible.

internettrans · 2021-12-27T21:16:26Z

Which bug in transform-modules-commonjs you're referring to?
I don't think we ever need to forcibly change the module format - see my comment above about how I don't think babel will change module format unless explicitly told to do so via plugin, which is something controlled via babel config.

make-github-pseudonymous-again · 2021-12-22T13:00:49Z

Does transformed.sourceType really reflect the output format? Perhaps it makes more sense to assume output is module or fail if it is not given source is not applicable for format: "commonjs" (see https://nodejs.org/api/esm.html#loadurl-context-defaultload).

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?
I do not know, I am just confused as to whether sourceType corresponds to the input sourceType or the output sourceType, since source carries an input meaning to me. Experimental node loader uses the source keyword for both "input" and "output" but the babel equivalent is transformed.code. I could not find the Babel documentation that explains what transformed.sourceType means. If you can find it please share.

make-github-pseudonymous-again · 2021-12-22T13:01:41Z

This is neat!

make-github-pseudonymous-again · 2021-12-22T12:58:14Z

I am nitpicking here but other formats include builtin, json, and wasm (see https://nodejs.org/api/esm.html#loadurl-context-defaultload). The logic makes sense. The comment could be improved.

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
Suggested change
// Skip transpilation of CommonJS modules.
// These modules are already preprocessed by Node.js,
// so we cannot parse the non-standard syntaxes like JSX and TypeScript.
// Their transpilation is better handled separately by @babel/register or @babel/node.
if(format!=="module"){
return{ source, format };
}
if(format!=="module"&&format!=="commonjs"){
return{ source, format };
}

I don't think that skipping compilation of commonjs modules is a good universal assumption, since babel is completely capable of compiling commonjs modules. I agree skipping json, wasm, and builtin formats makes sense. As a separate feature, I think that we could let users of node-loader-babel customize which files are compiled by providing their own useLoader function. But that wouldn't be part of this PR.
Looking forward what you say makes sense. It may be that one day node loader handles the source key for {format: 'commonjs'}. But insisting on commonjs being transpiled now makes little sense. As far as I understand, with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null. Babel gracefully handles null by producing null with little overhead. If one day source is non-null and has meaning for format = 'commonjs' suddenly this loader will start transpiling CJS input without warning. Not sure if this is a real stability threat but I feel like it is a bad idea to leave this open for this code to be general just in the case of "if ...".
I agree this behavior could be configurable by the user of node-loader-babel. I just think the default should be to only process 'module' input.
Note that without this PR, when input format is commonjs, input and output source are null and output format is module which is the reason of the bug described in #7.

As far as I know, Babel doesn't change the format of modules by default (unless you add a plugin that does it). Babel preset env doesn't seem to do so by default (see this repl). So I would think it's safe to let babel just compile the file like normal?
In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?

In this REPL, enabling @babel/preset-env does transform ESM input into CJS output. How do you configure it so that it does not change format?
Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
https://babeljs.io/docs/en/babel-preset-env#modules
I just think the default should be to only process 'module' input.
I can see how that would help solve the immediate problem, but don't think it's actually the proper behavior for node-loader-babel as a whole. If we can get babel to output the correct module format, there's no reason to avoid compilation of CJS files.
with the code of this PR, a commonjs input will have const {format, source} = await defaultLoad(...); such that format = 'commonjs' and source = null
Why would source be null? Does nodejs' default loader not provide commonjs source as a string? If so, then perhaps your suggestion of disabling would make more sense. But I thought that nodejs would give us the source as a string.

Set babel preset env's modules option to false. The "auto" value also should work if we have called babel with the proper options
OK. I cannot find how to do this in the REPL, maybe it is not possible.

internettrans · 2021-12-27T21:16:26Z

Which bug in transform-modules-commonjs you're referring to?
I don't think we ever need to forcibly change the module format - see my comment above about how I don't think babel will change module format unless explicitly told to do so via plugin, which is something controlled via babel config.

make-github-pseudonymous-again · 2021-12-22T13:00:49Z

Does transformed.sourceType really reflect the output format? Perhaps it makes more sense to assume output is module or fail if it is not given source is not applicable for format: "commonjs" (see https://nodejs.org/api/esm.html#loadurl-context-defaultload).

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?

I don't know why transformed.sourceType would not reflect the real output format. Are there bugs in babel or common plugins that make this wrong?
I do not know, I am just confused as to whether sourceType corresponds to the input sourceType or the output sourceType, since source carries an input meaning to me. Experimental node loader uses the source keyword for both "input" and "output" but the babel equivalent is transformed.code. I could not find the Babel documentation that explains what transformed.sourceType means. If you can find it please share.

make-github-pseudonymous-again · 2021-12-22T13:01:41Z

This is neat!

-Original file line number
+Diff line change
@@ Expand Up / @@ -10,6 +10,13 @@ describe(`basic babel usage`, () => { @@
  });
  });
+ it(`allows loading CJS modules`, async () => {
+ const example = await import("./fixtures/basic/cjs.cjs");
+ assert.deepEqual(example.default, {
+ cjs: "cjs",
+ });
+ });
  it(`supports ES module babel config files`, async () => {
  const mjsConfig = await import("./fixtures/mjs-config/main.js");
  assert.deepEqual(mjsConfig.default, {
@@ Expand Down @@

Original file line number	Diff line number	Diff line change
		@@ -0,0 +1 @@
		exports.cjs = "cjs";

-Original file line number
+Diff line change
@@ Expand Up / @@ -10,6 +10,13 @@ describe(`basic babel usage`, () => { @@
  });
  });
+ it(`allows loading CJS modules`, async () => {
+ const example = await import("./fixtures/basic/cjs.cjs");
+ assert.deepEqual(example.default, {
+ cjs: "cjs",
+ });
+ });
  it(`supports ES module babel config files`, async () => {
  const mjsConfig = await import("./fixtures/mjs-config/main.js");
  assert.deepEqual(mjsConfig.default, {
@@ Expand Down @@

Original file line number	Diff line number	Diff line change
		@@ -0,0 +1 @@
		exports.cjs = "cjs";

-Original file line number
+Diff line change
@@ Expand Up / @@ -10,6 +10,13 @@ describe(`basic babel usage`, () => { @@
  });
  });
+ it(`allows loading CJS modules`, async () => {
+ const example = await import("./fixtures/basic/cjs.cjs");
+ assert.deepEqual(example.default, {
+ cjs: "cjs",
+ });
+ });
  it(`supports ES module babel config files`, async () => {
  const mjsConfig = await import("./fixtures/mjs-config/main.js");
  assert.deepEqual(mjsConfig.default, {
@@ Expand Down @@

Uh oh!

Skip transpilation of CommonJS modules#8

Uh oh!

Skip transpilation of CommonJS modules #8

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

make-github-pseudonymous-againDec 28, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

make-github-pseudonymous-againJan 5, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Skip transpilation of CommonJS modules#8

Uh oh!

Skip transpilation of CommonJS modules #8

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

make-github-pseudonymous-againDec 28, 2021• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

make-github-pseudonymous-againJan 5, 2022• edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Skip transpilation of CommonJS modules#8

Uh oh!

Skip transpilation of CommonJS modules #8

Uh oh!

Uh oh!

Diff view

Diff view

There are no files selected for viewing

Choose a reason for hiding this comment

make-github-pseudonymous-againDec 28, 2021•
edited
Loading

make-github-pseudonymous-againJan 5, 2022•
edited
Loading

make-github-pseudonymous-againDec 28, 2021•
edited
Loading

make-github-pseudonymous-againJan 5, 2022•
edited
Loading

make-github-pseudonymous-againDec 28, 2021•
edited
Loading

make-github-pseudonymous-againJan 5, 2022•
edited
Loading