Node.js
Replies: 79 comments 155 replies
This comment has been hidden.
This comment has been hidden.
-
|
I vaguely recall a |
Beta Was this translation helpful? Give feedback.
-
|
Further discussion from the modules repo nodejs/modules#296 I found two more issues, I think it's better to wait for someone who was active at the modules team to say what ended up happening that caused Edit: found it #27184 Edit2: found the reasoning nodejs/modules#300 (comment) |
Beta Was this translation helpful? Give feedback.
-
|
Thanks for helping me find those links. I completely disagree with the reasoning stated there (I don't care if it was "package-type" or "entry-type", just would want some way to do it)... but I don't have the energy to try to re-litigate it. |
Beta Was this translation helpful? Give feedback.
-
|
@getify, those decisions aren't etched in stone. We may be able to accommodate you especially if you would be interested in making a pull request. Having a flag as you describe does seem useful to me. |
Beta Was this translation helpful? Give feedback.
-
|
If you're writing a file that has no associated package.json, how would you expect to convey (for invocations beyond the current one) the parse goal of the file beyond the extension, given that |
Beta Was this translation helpful? Give feedback.
-
|
Would there be a problem if we added a flag that allows the user to change the default behaviour ? |
Beta Was this translation helpful? Give feedback.
-
|
@targos it would encourage people to use a file extension that doesn’t match the parse goal of their file, without an accompanying package.json to carry that information. |
Beta Was this translation helpful? Give feedback.
-
|
one more time: this is not a module import {random} from 'library';
console.log(random());the fact All main bundles/files on the Web also are not modules: these are programs, that use a module system, yes, but these are not modules. index.mjs is not a module, if it doesn't export a thing, is a program. But yeah, this has been discussed for ages already. |
Beta Was this translation helpful? Give feedback.
-
|
Okay. So similarly a commonjs module is any script file that's in |
Beta Was this translation helpful? Give feedback.
-
|
Correct. |
Beta Was this translation helpful? Give feedback.
-
|
Now if we want to tell if it's an ES6 module or CJS module. How will one do it statically? I am aware that it can have |
Beta Was this translation helpful? Give feedback.
-
|
You simply can't in 100% of cases, because Script and Module are ambiguous parse goals. Anything with The file parse goal must be declared somewhere else out of band. For files, that's usually the file extension; for web servers, that's the MIME type (which browsers decide based on |
Beta Was this translation helpful? Give feedback.
-
|
Thank you, @ljharb ! This makes sense. Based on what I understand from this discussion this is how I would put my thoughts. Module: It is a concept that helps splitting JS files into multiple files so it helps in maintenance. The difference really is that commonjs module system loads JS file synchronously. However, ES6 module system loads file asynchronously. Some context: @SandZn, @bbaudry, and I are looking into debloating npm packages (mostly for server-side packages). Hence, we need to define such stuff to be clear about our research. |
Beta Was this translation helpful? Give feedback.
-
|
Last one, for correctness, and completeness, sake: <script type="module" src="program.js">The type there doesn't practically define the parsing goal, it defines the module system, and it propagates with it, because Something like: node --type=module --force-type=true program.jscould enforce the module system and its propagation, so that by default everything imported by program.js would have a module system, by default, that is ESM, not CommonJS. That's how you could define the parsing goal, but there's never been interest in doing this, although tons of developers keep asking for this, so I wish this common request was more welcomed, or developers expectations acknowledged.
'cause this is sad, but from personal experience, also true ... current state is more opinionated than concrete, imho, while competitors factor out this gotcha for developers (see deno). edit node --default-type=module program.js
node --input-type=module --override-default-input-type=trueall variants that could make it, if there was the will to do so. |
Beta Was this translation helpful? Give feedback.
-
BackgroundI built a tool called moduloze that converts a tree of commonjs-style files to either UMD or ESM style files. It's designed either to be used as a one-time codemod for code authors wishing to permanently convert to ESM, or (my use) for package authors who still prefer to write in commonjs but who want to distribute also in UMD and ESM formats for wider consumption flexibility. I have all my main/active npm packages using it. Along with that, I also have a tool called import-remap which allows you to apply import-map style rewriting of your import specifiers as a build-tool (instead of runtime aliasing). I also use import-remap in some of my projects to modify the output from moduloze to be ESM that's more readily useable in the browser. So, taken together, these two tools give authors a narrower-focused, and more flexible/less opinionated path (than, say, typical all-in-one bundlers) for supporting code that's CJS, UMD, and ESM, at the discretion of the users of my tools. Note: It is not a goal to interop between formats, but to support building parallel trees of code for each format. In that spirit, these tools (moduloze particularly) allow you to specify that you want your built ESM modules to be either .mjs or .js file extension. I offer that choice because I don't want my opinions on that topic to limit others. If they choose to make .js files with ESM code in them, they are responsible to either use that code in an environment like the browser where the script tag conveys the format, or in Node with some supporting configuration (e.g., a package.json). Use-CaseI would like to be able to test the various combinations of outputs from my tools (both automated test suites, and user-opt-in verification steps when the tools are used on user-code). I find it annoying/inconvenient to have to create a stub package.json file in a directory of built ESM-containing .js files with nothing but It's mildly annoying to need it for my tool test suite, but it's especially annoying for the opt-in at-use-time verifications performed on user-code the tool just outputted, since such a file has to be created just to invoke Node then deleted right after... every time. I would strongly prefer to have a flag like I've read all the linked threads (and comments here) and I'm aware of the objections to such a feature -- i.e., general users can't/shouldn't be trusted with such a feature. I disagree with these assertions, but don't need to have them repeated here, and I don't care to re-debate it. I've stated my use-case for posterity sake. I'll leave it at that, as I suspect it won't sway the strong opinions held by some in charge of Node's direction with modules. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW,
It'd be great if this issue would be re-considered/opened (among others) instead of keep hearing, here and there, alternatives are much better, so thanks in advance for considering this. |
Beta Was this translation helpful? Give feedback.
-
|
II think the discussion would be more productive if there were a PR implementing such a flag. Let's reopen to see if there are volunteers to work on that. |
Beta Was this translation helpful? Give feedback.
-
|
FWIW I think the ask here is pretty reasonable. @ljharb given the use case and the suggestion (a |
Beta Was this translation helpful? Give feedback.
-
|
@benjamingr Personally, I think |
Beta Was this translation helpful? Give feedback.
-
|
As a workaround, I'm using esm-ts-node. This is not the answer to your question, but I was looking for the same kind of option and found your issue. Maybe this can help. |
Beta Was this translation helpful? Give feedback.
-
|
Package hasn't been updated. Considering it's just script must be okey, right? |
Beta Was this translation helpful? Give feedback.
-
|
An interesting additional use-case for this flag from @rauschma: when you want to force a file to be treated as ESM when the file has no file extension, like typical *nix CLI tools look. |
Beta Was this translation helpful? Give feedback.
-
|
If there was a separate binary for ESM entry point (I don't think we have consensus on that, but let's assume for the sake of argument), tools could use the shebang to detect the file is ESM. However, there would still be ambiguity if that extensionless file is // ./esm-entry-point
#!/usr/bin/env node-esm
console.log(this === undefined ? 'ESM' : 'CJS');// ./cjs-entry-point
#!/usr/bin/env node
'use strict';
require('./esm-entry-point');If the entry point is |
Beta Was this translation helpful? Give feedback.
-
|
I was not suggesting reading the file. I would say in that case it should be parsed as CJS. Sorry, maybe I misunderstood the issue, I envisioned only the entry point (i.e. a main program executable/"bin") would be extensionless and nothing would require/import them. They would be importing other modules. I don't think extensionless module files is a good idea, but maybe there's a use case I'm not thinking of. The current behavior of |
Beta Was this translation helpful? Give feedback.
-
|
But I know it does not help much the problem weswigham mentioned of other tooling not knowing what kind of file it is. I guess other tooling might be able to read the first line to determine the type, if they are already parsing files it might not be too much overhead. But I tend to agree, having the information in a known location like package.json is probably better. Having an official node-esm binary and having Node docs specifying the exact form of the shebang line (i.e. specify that it should be exactly "#!/usr/bin/env node-esm", not "#!/usr/bin/node-esm", no extra spaces etc.) would help simplify if any tooling was going to read shebangs, so there are not a variety of different cases in the wild to handle. Not really related, but I think Python looks for standard shebang lines in some cases, to determine things like which version of the runtime to run, allowing them to work on Windows too (I think through the py.exe wrapper). |
Beta Was this translation helpful? Give feedback.
-
|
TBH, this line of discussion -- basically "we shouldn't do this because a file that requires this flag to work, won't necessarily work in other places without the flag" -- feels like a distracting red herring. I'm not trying to be rudely dismissive of the concern, I just think that concern is entirely misplaced. It is already the case, and has always been the case, that I can author a file that runs in Node under certain circumstances and doesn't run under others. That file authoring, and those circumstances, can be quite varied in their pairing, but there are many such examples. Take the And here's the point: that was ENTIRELY the right and purview of a userland developer to choose to do so, knowing the limitations. They didn't, and wouldn't, have the expectation that they could omit the known-required flag, and that file would still magically work as if the flag had been set. They knew that they needed the flag present to make sure the file was properly running. It is, in my estimation, a self-imposed and artificial limitation/objection, to suggest that we shouldn't have a flag that allows a file to be used in a certain scenario, merely because such a file couldn't be used in other scenarios where the flag wasn't present. Nobody should rightly expect that it would, and to my knowledge, nobody here is asking for it. To block this feature as if that's an expectation is almost strawman argument level misdirection. The idea, while perhaps noble, that Node should be able to figure out how to run any file under any scenario, and have any mix of files and scenarios, and they all just work... I can understand why that seems attractive. But returning to my original use-case, let me illustrate the flaw in this thinking. Put simply, the flaw is in thinking that Node is the only intended target for a file that would only work in Node with this flag. There are of course many other target environments where I might use a file besides Node, and it might be entirely valid that I know and am fine with the fact that using such a file in Node can only be done with this flag. That's not bad or broken feature design in any way, it's exactly what I would know and expect. My specific use-case was, I have a tool that converts CJS style module code into both UMD and ESM representations. It's intended mostly for -- and indeed, this is how I myself use it exclusively -- package authors who write "universal" (or "isomorphic" or whatever silly label) code that can run in both Node and in the browser, and want their package build and distribution (on npm) to include all 3 formats (CJS, UMD, and ESM) to give maximum flexibility for end users. This tool allows, via flags/config, to set the filename extensions of the converted ESM files. By default, it would produce files with A feature I really want to add to my tool is, that you can provide a "test" command to the tool, which runs test(s) against the code in both of the built formats (UMD and ESM). This is basically like wanting to verify that the built files in fact still function the way you expect (and the way the original source CJS files behave with your test suite). So my module-conversion tool has constructed a set of ESM code (one or more files), in a specific build directory that the user arbitrarily specifies, all (potentially) with The problem now is, I can't cleanly force Node to treat all those These ESM files with So we return to what I claim is the flaw in thinking. Node isn't the only target environment someone may have in mind whenever they decide to put ESM code into a This whole year-long thread has been filled with all sorts of distractions about "what if" things like conflicting package.json info, traversing up the file system, and mix-n-match import of these files, etc. None of that is relevant to the use-case point at hand: a user makes a I wish we would stop complicating the issue with all the other what-ifs, because those what-ifs are artificially constraining the situation in unrealistic ways. Nobody who ever uses this flag on a certain All this flag needs to do is let me run a certain file in Node that perhaps might not otherwise ever be able to run in Node in any other usage. That's not broken or weird or inconsistent. That's an entirely valid condition, and it's one Node should support rather than shun. |
Beta Was this translation helpful? Give feedback.
-
There's also the |
Beta Was this translation helpful? Give feedback.
-
|
to provide an update on this, with the current state of the --experimental-loader=loader.js api i was able to provide a loader.js that relies on the default resolve() hook's determination of "commonjs" modules before entering the load() hook, where it attempts to load them as es modules if a tentative commonjs resolution (with createRequire) fails due to module-related syntax error, by overwriting the determined context.format key. getify's concern for undeterministic "format" keys due to lack of file extension or require- or unix-like extensionless specifiers can be solved by additionally returning the source text in a "code" field and shortCircuit to prevent the failure of the default hook (if(!/.js$/.test(url))return {code:read(url+".js"),shortCircuit:true};). The tentative require only to verify commonjs may be expensive, but this is used in scenarios where commonjs is not favored anyway. The module-like syntaxerror verification could also be elaborated, i have only encountered "cannot use import outside a module" and "invalid token 'export'" errors when writing this. my use case has been importing unbuilt package source codes written in inaccessible es, with their package.json only specifying the to-be-built target's type, and the source's syntax only being implied in rollup configs (eg. acorn, but source syntax is commonly encrypted in various inscrutible build configs nowadays). the justification to do this was a bundling tool that relies on acorn, but capable of building acorn itself (in which case acorn is not readily available, and automatically building it - as possibly any other package - seemed more difficult and expensive to fathom than just expecting its source to be coherent before it's bundled). the use case may be debated, but it's not strictly relevant to the subject issue. import {createRequire} from "module";
const require=createRequire(import.meta.url);
export function load(url,context,next)
{if(context.format==="commonjs")
await require(url).catch(fail=>
{let syntax=fail.constructor.name==="SyntaxError";
if(syntax&&["import","export"].some(token=>RegExp(token).test(fail.message))
return Object.assign(context,{format:"module"});
throw fail;
});
return next(url,context);
}); |
Beta Was this translation helpful? Give feedback.
-
|
@bpstrngr to provide you with the needed updates expermental loaders can be seen as deprecated and got superseeded by --imports[] array flag that loads ESM before frozen intrinsics like --require[] did before hope that helps you a little bit |
Beta Was this translation helpful? Give feedback.
-
|
@lemanschik do you mean #40110 ? it seems to be about pre-loading modules that produce sideeffects before an actual entry point, the type of which will still only be determined by a package.json. it serves the purpose for invoking independent es modules without a package.json indicator, but what about dynamic imports? if a package.json in an intermediate directory exists and doesn't specify type:module, it will be assumed as commonjs. granted, that's beyond the discussion's scope, which this import flag resolves indeed. |
Beta Was this translation helpful? Give feedback.
-
|
@bpstrngr uff you are correct but ok for the new web that does not matter any more we will register via import a own loader that has hooks in it and registers a dynamic ESM loader callback. But your correct for the nodejs internal part. I guess overall the VM module needs to get simply aligned the flags on start do not matter as much as long as you can load at the end something that can load as desired. Overall nodejs should simply switch to handle ESM by default and then .cjs and a flag indicate additional stuff. I internal experiment since a longer time with a pattern where i monkey patch require to use import by default while doing so i used a little trick that typescript uses to indicate while parsing if something is Module or Script Typescript explicitly needs |
Beta Was this translation helpful? Give feedback.
-
|
maybe we could align with the new web-modules api it is implemented already for wasm https://github.com/lemanschik/wasm-component-system/blob/main/README.md it implements a wasm component system on sharedMemory i want to do the same for nodeJs in general to get easyer Interop between nodeJs and our existing browser components. nodejs got invented as chromium got no component system this changed the last years. now it would be time that nodejs adopt the chromium patterns. as it is based on chromium and not chromium based on NodeJS The WebAssembly.instantiate Streaming() function compiles and instantiates a WebAssembly module directly from a streamed underlying source. This is the most efficient, optimized way to load wasm code. And so is also true for ESM this handels load via fetch and instantiation the so called load async independent code able with the stream interface to prevent users from writing locking logic and queues. they include error propagation and back pressure and all that. As also none documented hardware clocking scheduling algorithms in experimental state to sync clock execution cross cluster of modules on web scale size. Mini Exampleconst wasmModuleBasedInputSource = new ReadableStream({ start: async ({ enqueue: imported_func }) => (await WebAssembly
.instantiateStreaming(fetch("simple.wasm"),
{ imports: { imported_func } }) ).instance.exports.exported_func() });so put instantion into userland! this way the user of the runtime gets loader feedback as he does in the browser if he wants to but can also simply ignore that. this is adaptable. only action able itm is to add a extra api to your fetch implementation that does module instantiation in userland. already using working workaround polyfill via import data url in nodejs and blob in the browser to create reference able memory for the result that is reusable cross module system in general fetch and import already supply everything but the user is not aware of what he is doing. import returns in fact instance.exports already. but the user is not aware that this is a reusable sharedMemory reference. with a loader api like the WASM one expressed maybe as await ESModule.instantiateStreaming(fetch) could shape the mind set of the user into the right directions. |
Beta Was this translation helpful? Give feedback.
-
|
This is something TC39 is working on; it wouldn’t make sense for a host to implement it prior to that. |
Beta Was this translation helpful? Give feedback.
-
|
I honestly don't see how any of this relates to the original thread I asked. |
Beta Was this translation helpful? Give feedback.
-
|
It is not possible to specify the module type using a command-line parameter when running a Node.js program. The module type is determined by the file extension of the imported module. For example, if a file has a .js extension, it will be treated as a CommonJS module. If it has a .mjs extension, it will be treated as an ECMAScript module. If you want to force a specific module type for all imports in your program, you can use the --input-type flag when running the program with the node command. For example: This will treat all imports in the index.js file as ECMAScript modules, regardless of the file extension. Note that this flag only affects the entry point file specified on the command line, and not any imported modules. Alternatively, you can specify the "type" field in the "main" field of your package.json file to specify the module type for the entry point of your program. |
Beta Was this translation helpful? Give feedback.
-
This missing feature is precisely what is the current feature request about! Node.js scrips are often launched as a single script file from cli, without |
Beta Was this translation helpful? Give feedback.
-
|
as long as electron is not esm ready, its pretty bad to be left without the options. |
Beta Was this translation helpful? Give feedback.
-
|
Having similar issues with two different projects, one based on serverless-framework serverless offline, which doesn't seem to like setting "type":"module, and Jasmine 4 which basically requires it. It would be nice to set the module type in CLI only for Jasmine so I can run my tests. Until its all ESM I have to manually add "type":"module" to package.json for tests and remove it when tests are done. |
Beta Was this translation helpful? Give feedback.
-
|
** Sarcasm ** What's wrong? Can't you just use libraries that support esm already? Don't like manual work? Somebody inside the node team made this decision not taking into account a lot of things that will break. On the other hand I've been toying with the language server and I really see the other side, sadly its easier to blame a choice than to see the bigger picture ... |
Beta Was this translation helpful? Give feedback.
-
|
I'm in the same boat here! Very annoying. |
Beta Was this translation helpful? Give feedback.
-
|
Same here. Ridiculous. |
Beta Was this translation helpful? Give feedback.
-
|
I've been here, done that. |
Beta Was this translation helpful? Give feedback.
-
|
For what is worth, I found an esoteric solution, that I'm quite sure will not be helpful for many, but I will post it here just in case someone needs help. Using Jasmine for tests, I found that if I add nyc to my test run command I can get this to work. I have no idea why. "test": "cross-env APP_ENV='test' nyc jasmine JASMINE_CONFIG_PATH=jasmine.json", I then can remove type:module from my package.json If anyone finds this useful then great |
Beta Was this translation helpful? Give feedback.
-
|
Hitting this because we have systems that (by default) install some lower level dependencies into a directory that isn't Ideally settings originating from the |
Beta Was this translation helpful? Give feedback.
-
|
Hello great community of node.js. I think this ticket represents what is wrong with node.js - failure to observe backwards compatibility on language level (why I should ever need to specify what level of JS spec I am using with latest version of node?) and failing developers at the same time to force node.js to accept specific library and or script at specific language level. (yes, I know that I can put a package.json with override of language level after installing a package but, this is beyond pale. But completely consistent with how npm should not be used. Now I think that node.js can only be used by small home projects and should not be treated seriously) |
Beta Was this translation helpful? Give feedback.
-
|
Out of my view the only current solution that works well for electron and node js is bundling or usage of a loader. Thats true for nodejs and for electron. The most solid solution is the usage of rollup with with CJS support then loading it as CJS or bundle it as CJS Modules are great as Author format but not as execution format. That rule stays. |
Beta Was this translation helpful? Give feedback.
-
|
my only humble wish is to not have to carry a package.json along with my module to be able to load it. Modules are the standard ES syntax, so Node.js should be able to assume that at least with a flag, if not by default. I have figured out a solution with a --loader module to load dependency source files from folders where the package.json specifies the format of the transpiled (therefore in a clean repo clone nonexistent) commonjs, and not those ESM source files by falling back to context.type="module" in case of that sort of error. But the problem begins at the fact that i wrote that --loader module in the current standard ESM format, and i have no means to use That itself without a silly package.json tagging along only to specify {"type": "module"}. Which is, mind you, the standard format, in case i haven't mentioned it yet. |
Beta Was this translation helpful? Give feedback.
-
|
@ljharb well yes because i wasn't even thinking of .mjs. and i was interacting with the root of this discussion for that to be implied even more to me (i can see how that might not be obvious to track anymore in such a long discussion though). but i promptly re-specified it after you suggested .mjs (after which you still repeated your first answer), so now that that's certainly settled i'm still interested in hearing a substantial opinion about cons for a --type, --input-type or --package-type flag for .js module specifiers without a corresponding package.json. :D (to get one reasonable suggestion out of the way, one can pipe a .js sourcetext with --input-type but that doesn't modify the interpretation of --loader modules and makes it difficult to pass CLI arguments after the piped input, especially across various terminals). |
Beta Was this translation helpful? Give feedback.
-
|
tried to collect the most significant milestones in this discussion. An apparent first simple resolution, without followup: A criticism about package.json conflict: A criticism about tooling assumptions: A rebuttal to both criticisms: |
Beta Was this translation helpful? Give feedback.
-
|
@bpstrngr i will not jump into the details about the thing that i tell you now but you can try if it also fits your needs. The Engine has 2 Phases a so called Loading and a execution Phase after the first loading the so called intrinsics get frozen. So this is called none strict ESM in my terminology and i call it this way because you can mess up globals if you explicitly assign to them. But else it is like running normal code. node --import ./script1.js --import ./script2.js The --import flag is a flag that can be used multiple times it loads the scripts in order The other possible way is a loader like rollup it can transpile and then load on the fly. so you use eg: rollup to produce a array of modules and then imports.map(x=>import(`data:javascript/text;${x}`))i should maybe expand on the topic why rollup would be needed dynamic import from data url supports no resolve so all modules need to be pre resolved that's because data urls do not depend on the filesystem they are a nativ way to load code. |
Beta Was this translation helpful? Give feedback.
-
|
@lemanschik i remember when you suggested --import earlier too , and since then i have implemented a --loader module that indeed uses rollup, acorn and other parsers extensively to control formatting wrongly assumed from package.json in various internal imports (eg. source files being ESM, but the package.json representing only the transpiled commonjs build outputs, vice versa, or typescript/flow etc. simply having no native support), and as an on-the-fly package manager/bundler. So it solves all problems which were my priority when i responded to you the other time, but the entry point remains only controllable with a package.json. An --import flag's entry module will become ESM, but a --loader ESM can still only be applied to the internals if a package.json is present. It can be good for some who don't have conflicts with internal resolutions too. Even then it seems to reveal how there ought to exist a less sorry excuse hack for a solution... |
Beta Was this translation helpful? Give feedback.
-
|
@bpstrngr sorry i was maybe missing the most important way: npm i esm the esm module implements the ESM Loader inside the CJS context it allows the loading of ESM without package json as this depends on parsing the module upfront for import .....
export .....to check if it is ESM or CJS |
Beta Was this translation helpful? Give feedback.
-
|
This is now possible #50096 🎉 cc @getify (well, that and |
Beta Was this translation helpful? Give feedback.
-
|
why wasn't that a day 1 thing ... :( |
Beta Was this translation helpful? Give feedback.
-
|
It was waiting for someone like you to contribute |
Beta Was this translation helpful? Give feedback.
-
|
To be fair, this god-awful syntax is not exactly persuading people to do so. |
Beta Was this translation helpful? Give feedback.
-
|
@benjamingr you should also mention the more importent flag: https://nodejs.org/dist/latest-v21.x/docs/api/cli.html#--experimental-detect-module the --experimental-detect-module simple uses the same that typescript uses in classic resolve so both systems would have same behavior. |
Beta Was this translation helpful? Give feedback.
-
|
the issue he did link is about that detect-module flag. thanks for the docs link though, and the remark about ts seems valuable. |
Beta Was this translation helpful? Give feedback.
-
|
Hope |
Beta Was this translation helpful? Give feedback.
and others
-
I'm aware that I can name a file with
.mjsor set"type": "module"in package.json. I'm also aware of the--input-type=moduleCLI parameter.What I'm not understanding is, why isn't there a way to pass a parameter flag to force module interpretation for the
.jsfile I specify? Was there a reason that--input-typecan only be used with string input and not to control module interpretation of a.jsfile?I tried searching old issues to find this discussed but my searching failed me. I feel certain it must have been intentionally omitted, but I'm just trying to understand why?
Beta Was this translation helpful? Give feedback.
All reactions