Provide a way to add the '.js' file extension to the end of module specifiers #16577

quantuminformation · 2017-06-16T12:07:49Z

In order to use es6 modules in the browser, you need a .js file extension. However output doesn't add it.

In ts:
import { ModalBackground } from './ModalBackground';
In ES2015 output:
import { ModalBackground } from './ModalBackground';

Ideally I would like this to be output
import { ModalBackground } from './ModalBackground.js';

That way I can use the output in Chrome 51

<!DOCTYPE html>
<html>
<head>
  <meta charset="UTF-8">
  <title>Webpack boilerplate</title>
  <script type="module" src="index.js"></script>
</head>
<body></body>
</html>

Related to #13422

The text was updated successfully, but these errors were encountered:

cyrilletuzi · 2017-06-16T12:18:27Z

It's not just related to #13422, it's the same issue. But responses have been quite negatives, despite the fact I think it's a important issue, so hope your issue will be better received.

quantuminformation · 2017-06-16T15:46:44Z

Well, I hope its added, we were really looking forward to discussing my POC using this in my next TypeScript podcast, but looks like we will have to wait to use TypeScript with no build tools.

DanielRosenwasser · 2017-06-17T00:00:18Z

At the moment TypeScript doesn't rewrite paths. It's definitely annoying, but you can currently add the .js extension yourself.

DanielRosenwasser · 2017-06-17T00:01:47Z

@justinfagnani @rictic

quantuminformation · 2017-06-17T08:46:42Z

Thanks for the tip, I'll write a shell/node script to do this.

justinfagnani · 2017-06-18T02:22:36Z

@DanielRosenwasser would it make sense to collect the native ES6 module issues under a label?

justinfagnani · 2017-06-18T02:23:53Z

Also, to generalize this issue a bit, I don't think it's actually about adding a .js extension, but resolving the module specifier to an actual path, whatever the extension is.

quantuminformation · 2017-06-19T10:16:43Z

I've come across another issue which isn't really the domain of typescript but it's for my use case.

I'm not sure how to handle node_modules. Normally webpack bundles them into the code via the ts-loader but obviously, this is not understood by the browser:

import { KeyCodes } from 'vanilla-typescript;
https://github.com/quantumjs/vanilla-typescript/blob/master/events/KeyCodes.ts#L3

Adding a js extension here is meaningless.

I guess there would have to be a path expansion by typescript or a url resolver running on the server.

I appreciate its a rather niche case, but I think it would be a way TS could shine early in this area. Maybe it could be a plugin to the tsc compiler?

quantuminformation · 2017-06-22T16:06:48Z

For anyone coming to this and wants an interim solution I wrote a script to add a js file extension to import statements:

"use strict";

const FileHound = require('filehound');
const fs = require('fs');
const path = require('path');

const files = FileHound.create()
  .paths(__dirname + '/browserLoading')
  .discard('node_modules')
  .ext('js')
  .find();


files.then((filePaths) => {

  filePaths.forEach((filepath) => {
    fs.readFile(filepath, 'utf8', (err, data) => {


      if (!data.match(/import .* from/g)) {
        return
      }
      let newData = data.replace(/(import .* from\s+['"])(.*)(?=['"])/g, '$1$2.js')
      if (err) throw err;

      console.log(`writing to ${filepath}`)
      fs.writeFile(filepath, newData, function (err) {
        if (err) {
          throw err;
        }
        console.log('complete');
      });
    })

  })
});

I might make this into a cli tool..

aluanhaddad · 2017-08-09T03:30:16Z

@justinfagnani's comment hits the nail on the head.

Also, to generalize this issue a bit, I don't think it's actually about adding a .js extension, but resolving the module specifier to an actual path, whatever the extension is.

when you write

import { KeyCodes } from 'vanilla-typescript';

or for that matter

import { KeyCodes } from 'vanilla-javascript';

you are importing from an module specifier, it may or may not be a file but adding .js to the end in this case is not likely to result in a valid resolution.

If you are writing a NodeJS application then the NodeJS Require algorithm will attempt various resolutions but it will likely not attempt to resolve it to 'vanilla-typescript.js' because it references an abstract name and will, by convention and by configuration, be resolved (perhaps over various attempts) to something like '../../../node_modules/vanilla_typescript/index.js'.

Other environments, such as AMD have differences as to how they perform this resolution but one thing that all of these environments have in common is some notion of an abstracted module specifier.

I bring this up because the ES Module implementations shipping in various browsers implement something that is incomplete. If we consider even our simplest dependencies, and as soon as we broach the subject of transitive ones, it becomes clear that there will need to be a way to configure the doggone thing.

That may be far off, but as you are discovering, it is not realistic to write to this (politely) proof of concept implementation we have been given.

Furthermore, I do not see how TypeScript could possibly help here since the issue is environment specific.

@quantuminformation your program for adding .js to paths looks nice, lightweight, elegant even, but you are ultimately implementing your own module bundler. That is fun and interesting work but it demonstrates the deficiencies in the current implementations available in browsers. Even if you write in pure JavaScript, you still need something to compile and package your transitively imported dependencies.

I am basically just ranting about the fact that the implementation of ES Modules that was released is tremendously far from adequate.

Again NodeJS, RequireJS AMD, Dojo AMD, Sea Package Manager, CommonJS, Browserify, Webpack, SystemJS, all have their own differing ways of doing things but they all provide abstract name resolution. They have to provide it because it is fundamental.

Thank you for reading my rant.

AviVahl · 2017-11-10T23:04:49Z

Not sure which version of TS added it, but imports such as './file.js' now work (even if the file is actually file.ts).
TypeScript resolves the file fine, and outputs the complete .js import to the target.
lit-html use it: https://github.com/PolymerLabs/lit-html/blob/master/src/lib/repeat.ts#L15

cyrilletuzi · 2017-11-11T08:29:55Z

It's possible since TS 2.0. But tools like webpack don't support it so in the end it's useless.

AviVahl · 2017-11-11T12:27:32Z

It's useless if one is using ts-loader on sources (the most common use-case).
It is still possible to bundle the target (usually "dist" folder), as the actual js file exists there and can be found by the resolution process.

I wonder if I could implement a quick transformation in ts-loader that strips .js extensions from the target code, allowing one to bundle directly from sources.

cyrilletuzi · 2017-11-11T16:40:12Z

Feel free to do so, that would be great. I posted the issue on main webpack ts loaders, like ts-loader, a few months ago, and I've been quite badly received...

For information, there is no problem with the rollup typescript plugin, as a proof it's doable.

aluanhaddad · 2017-11-11T21:30:49Z

I fail to see what good this does until browser loader implementations and the WGATWG loader spec support at least some configuration because most dependencies won't load correctly.

From my point of view, none of this matters until it is practical to use the native loader on an import that refers to an arbitrary string literal specifier, something that may not yet be a URL, and have that go through a transformation that yields the actual URL.

Until then we will remain dependent on tools like SystemJS and Webpack.

AviVahl · 2017-11-11T22:45:18Z

I created a tiny transformer that strips the '.js' from import/export statements.
I used tsutils type guards, so yarn add tsutils --dev. (the package is usually installed anyway if you have tslint in your project, so so extra dependency)

https://gist.github.com/AviVahl/40e031bd72c7264890f349020d04130a

Using this, one can bundle ts files that contain imports from files that end with .js (using webpack and ts-loader), and still transpile sources to esm modules that can load in the browser (using tsc).

There is probably a limited number of use-cases where this is useful.

EDIT: I updated the gist to work with exports as well. it's naive and not optimized, but works.

quantuminformation · 2017-12-30T14:29:44Z

Any movement on this issue?

SalathielGenese · 2017-12-30T22:41:11Z

This matter of extension take us back to the very begining of TypeScript and why a tsconfig.json was needed and why a module option was added to the compilerOptions setting.

Since that matter of extension of extension matters only for ES2015+ as require is able to resolve quite well, let it be added by the compiler when targeted code is ES2015+.

.js for .ts
.jsx for .tsx

matthewp · 2018-01-12T18:36:11Z

Hello, I'm coming at this late but would like to help. I am having trouble understanding what the issue is here. From the OP example it is:

import { ModalBackground } from './ModalBackground';

Is the issue that we don't know what './ModalBackground' is? It could be a folder or something else?

If we run tsc on the entire project and we know that ModalBackground.ts exists, then we would know that it is safe to add the extension, no?

benlesh · 2018-01-12T22:07:36Z

This issue is also something the RxJS community is very interested in. What is the timeline on a solution for this? Is it even prioritized? Are there any third party transformations that would help?

TheLarkInn · 2018-01-12T22:25:53Z

I'm not really sure if this is a problem if the output target is ES2015 is it? This could maybe fall into the domain of a ES2015browser capability. Even more so, @justinfagnani can't we push for this as a platform goal to worry about? (Maybe need to fork into separate thread).

In Webpack 5+, this is required to load Svelte correctly, due to what appears to be code generation issues with TypeScript: microsoft/TypeScript#16577 This works around that by using telling end users to use a newly added feature in Webpack 5+, that uses Webpack 4 behavior for resolving module names: https://webpack.js.org/configuration/module/#resolvefullyspecified

See microsoft/TypeScript#16577 (comment)

FunctionPoint · 2021-01-04T21:02:07Z

Jeez, this is super annoying.
TypeScript transpiles to JS but then generates broken (modern) JS code.
Just add the option already to generate the ".js" extension for imports in transpiled JS
and make 1000's of developers happy...

pauldraper · 2021-01-04T21:42:12Z

TypeScript transpiles to JS but then generates broken (modern) JS code.

?

It works fine

example.ts

import { Example } from './example.js';

compiles to

example.js

import { Example } from './example.js';

FunctionPoint · 2021-01-04T22:05:43Z

Yes, thanks you, and apologies, sort of.
After posting I discovered that if you add the ".js" extension to the typescript import statement,
the code will be generated correctly (will not change) and typescript itself also keeps working with debugging option.
.
It still seems strange to me that you have to refer to not-yet-existing *.js files from their corresponding *.ts fles,
but hey, it works :-).

borfast · 2021-01-04T22:07:13Z

TypeScript transpiles to JS but then generates broken (modern) JS code.

?

It works fine

example.ts
import { Example } from './example.js';
compiles to

example.js
import { Example } from './example.js';

This same argument has been made before in this thread but it still doesn't make sense. You can not import something from a compiled file, especially one that hasn't been created yet. No other programming language allows that. Java doesn't allow you to import something from a .class file. C and C++ don't allow you to #include something from a .o file.

db984 · 2021-01-04T22:11:09Z

example.ts

import { Example } from './example.js';

I'm writing in typescript; importing something from a local path in the same project that only contains typescript files. How does appending a .js to the import statement make sense to you? We're not writing any javascript and there's no javascript file in the folder being referenced?

The .js file being referenced doesn't exist; and won't exist until after it's been transpiled to js, and when that happens in many cases it'll be stored somewhere else. Source code shouldn't be referring to it's own build artifacts.

At the very least, if I'm going to reference importing from another typescript file by name, it should be:

import { Example } from './example.ts';

I further agree with the complaint that I shouldn't have to put the extension at all; let me just refer to ./example, and the transpiler can find the relative .ts file. And the transpiler should be responsible for appending .js in the transpiled output,

We really shouldn't have to provide the ".js" in the .ts source code.

FunctionPoint · 2021-01-04T22:21:43Z

For the record, I totally agree with @db984
that this is a bug / design flaw that should be fixed asap.
But the workaround that works for me is importing *.js modules from the *.ts files,
even if they don't exists yet with a clean build.
FYI: I'm using latest: VSCode 1.52.1 and TypeScript 4.1.3, Edge 87.0.664.66.

pauldraper · 2021-01-05T05:01:41Z

You can not import something from a compiled file, especially one that hasn't been created yet. No other programming language allows that. Java doesn't allow you to import something from a .class file.

No, that's exactly what Java does. Exactly.

import org.example.Example, means that the .class file is (or will be) located at org/example/Example.class on the classpath. Whereas the file structure of .java sources doesn't matter in the least...every .java source file from every package could be in one directory; javac doesn't care. Imports refer to .class file structure.

C and C++ don't allow you to #include something from a .o file.

Which makes sense because C/C++ includes are done as text preprocessing on the source files. Whole different approach, whole different ballgame. Forget knowing about compiled files, gcc -E and #include is a templating language isn't even aware what actual C is.

If you're requiring the "file to exist", you should also have a problem with the "non-existent file" lodash in

import * as _ from 'lodash'

The answer is that lodash isn't a file, it's a module specifier.

TypeScript doesn't change module specifiers. You can use lodash, lodash/index, /home/me/project/node_modules/lodash/index.js, https://example.org/js/index.js, etc. and TS respects your choice.

TS doesn't know anything about JS file<->module specifier relationships. It just knows how to resolve TS types from module specifiers. TypeScript plays around with extensions (.js, .ts, .jsx, .tsx, .d.ts) and directories (@types) and even uses selective parts of files (declare module 'lodash' {})

If you import from lodash or lodash/index.js, TypeScript will attempt the various extensions and directories in it's algorithm to find the types for that JS module. This is how it has always been, for every import ever.

I further agree with the complaint that I shouldn't have to put the extension at all

Then use a module loader that works with extensionless module specifiers.

But if you're interested in a module loader (native ES modules) that requires the exact path of the JS modules, know that TypeScript in fact supports using the exact path of the JS module. (Said differently, TypeScript supports locating TS types using the exact path of the JS module.)

MicahZoltu · 2021-01-05T06:04:45Z

Yes, thanks you, and apologies, sort of.
After posting I discovered that if you add the ".js" extension to the typescript import statement,
the code will be generated correctly (will not change) and typescript itself also keeps working with debugging option.

It still seems strange to me that you have to refer to not-yet-existing *.js files from their corresponding *.ts fles,
but hey, it works :-).

@FunctionPoint as an alternative option, you can use a compiler plugin to add the extension at compile time: https://github.com/Zoltu/typescript-transformer-append-js-extension

borfast · 2021-01-05T17:47:05Z

@pauldraper,

No, that's exactly what Java does. Exactly.

No it's not and you know exactly what I meant 🙂

What Java allows us to do is to import source files, not compiled files. It may so happen that in the compiled Java bytecode it does reference a file ending in .class (probably not but I don't recall how it works) - but that's the compiler's decision, not ours. This is the main point you're missing: it's not about what letters you type after a dot; it's about forcing us, developers, to do something that is inherently wrong, which is to do the compiler's work by referencing build artifacts. It's not our responsibility, nor should we touch this in any way.

@db984's reply is spot on.

db984 · 2021-01-05T20:39:51Z

Where @pauldraper writes:

If you're requiring the "file to exist", you should also have a problem with the "non-existent file" lodash in
import * as _ from 'lodash'
The answer is that lodash isn't a file, it's a module specifier.

A bare module specifier is a completely separate case. Here we are clearly relying on the compiler/runtime and project configuration to help it find a module named "lodash". Perhaps the file being imported is in ./node_modules/lodash/index.js or perhaps its somewhere else. But its pretty clear that all the source code says is that its in the "lodash" module.

When I import from '../../services\core\example' without any extension, to me at least, that looks like an import of a module named example from a specific location. I'm telling it where to look for the example module, but still not giving it a filename. And that works, and is logically consistent, because that is the path to where the source code for the module named example lives but I'm still relying on the compiler and runtime etc to figure out the file name to import. I'm just naming a module and saying where to look for it.

But when I import from '../../services/core/example.js' with the js extension, that now looks an awful lot like a specific file in the source tree, given explicitly by filename. Yes, there is source code for a module there named example, but its in a file called example.ts that I expect will be transpiled to example.js in the output folder at some point, and that is an extremely clumsy solution; because nowhere in my source tree do I have anything called example.js so it doesn't make a lot of sense to be referencing it.

To argue that '../../services/core/example.js' is also really a just a module specifier may be technically correct, but its un-intuitive because it's also clearly a file reference and it doesn't resolve the complaint that '../../services/core/example.js' doesn't actually exist.

It seems far more logical to me that typescript should explicitly support typescript source code esm modules that are part of the project and allow you to reference '../services/core/example.ts' with a ts extension, and when it transpiles the referenced ts file to a js module it can swap in the .js extension in the transpiled output. Then I'm referencing a file that exists in the source, and leaving it to transpiler to transform it to a suitable valid module reference in the output.

And again, I would go even further and also allow you to leave the extension off entirely, and it will look for the module specified at that path, much as it does for commonJS modules, even though that's not in the javascript esm standard. It's doing a transpilation step anyway, so it can do the legwork of resolving the the module specifier to a file reference. I'm using typescript because it makes life easier after all.

shicks · 2021-01-05T20:49:08Z

I agree that in an ideal world, TypeScript could take total ownership of the import paths and remap them appropriately.

But tsc doesn't always (often) have visibility into where the *.js artifacts actually live - its resolution is looking for *.d.ts files in many cases, so any such rewriting would be spotty at best. Given the inconsistency, the next best thing is to just not touch it at all, which is the current behavior.

db984 · 2021-01-05T21:57:57Z

its resolution is looking for *.d.ts

a) This already deviates from javascript; so 'not touching it at all' is already not accurate.

b) It's been working fine for project relative imports in commonJS all this time, with very similar constraints so I'm really not sure why you think this is a significant challenge where support could only be "spotty at best".

As near as I can tell the only real change is that esm module resolution standard requires the explcit .js extension when referencing importing a js file from a relative location where as the commonJS standard specified that it would search filename.js then filename.json etc automatically in this case.

RyanCavanaugh · 2021-01-05T22:31:16Z

Well I've read all 385 comments again now as part of a FAQ update and here are my main takeaways:

We are not going to implement features, even under a commandline flag, that imply changing JS semantics by rewriting it during emit
.js file extensions are now allowed, which was not true when OP was written, so the issue as described has been fixed
We are 100% committed to not rewriting JavaScript code as part of non-downleveling compilation. This is how everything else in TS works; see also this comment in a related feature request, and this comment in a related feature request. We are not going to implement features, even under a commandline flag, that imply changing JS semantics by rewriting it during emit
Everyone should read this comment from this thread as it accurately summarizes the rest of the discussion IMO

Experience on these sorts of threads has shown that discussion tends to just remain circular at this point, so I'm going to lock to avoid notification noise for commentors and repo watchers. We are not going to implement features, even under a commandline flag, that imply changing JS semantics by rewriting it during emit.

quantuminformation mentioned this issue Jun 16, 2017

TypeScript and <script type="module"></script> #13422

Closed

DanielRosenwasser added the Suggestion An idea for TypeScript label Jun 17, 2017

DanielRosenwasser changed the title ~~Add .js file extensions to import declarations output for use in Chrome 51 ES6 module imports~~ Provide a way to add the '.js' file extension to the end of module specifiers Jun 17, 2017

DanielRosenwasser added the Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. label Jun 17, 2017

DanielRosenwasser added the Domain: ES Modules The issue relates to import/export style module behavior label Jun 18, 2017

quantuminformation mentioned this issue Jun 22, 2017

Would it be a good idea to return a reference to the file instead of the file path? nspragg/filehound#64

Closed

tkrotoff mentioned this issue Aug 29, 2017

incoming Safari 10.1 module support #14861

Closed

demurgos mentioned this issue Nov 14, 2017

Support .mjs output #18442

Closed

kwonoj mentioned this issue Jan 12, 2018

Compile TS to native JS modules ReactiveX/rxjs#2858

Closed

syvb mentioned this issue Oct 28, 2020

Document workaround for Svelte errors sveltejs/svelte-loader#141

Closed

JannesMeyer mentioned this issue Oct 29, 2020

Support for .js files without internal TypeScript compilation Testy/TestyTs#55

Open

getkey added a commit to getkey/epix that referenced this issue Nov 22, 2020

Output full paths, including the extension

7c8029c

See microsoft/TypeScript#16577 (comment)

natemoo-re mentioned this issue Nov 23, 2020

Microsite pins a CPU core on creation and building, no output natemoo-re/microsite#40

Closed

fernandopasik mentioned this issue Dec 2, 2020

Compilation errors when building with webpack 5 fernandopasik/react-children-utilities#24

Closed

ctjlewis mentioned this issue Dec 30, 2020

TypeScript cannot emit valid ES modules due to file extension issue #42151

Closed

11ume mentioned this issue Jan 3, 2021

Javascript ES6 module support 11ume/wezi#50

Closed

FarazzShaikh added a commit to FarazzShaikh/WebAssemblr that referenced this issue Jan 4, 2021

Worked around microsoft/TypeScript#16577

023cfb6

RyanCavanaugh added Declined The issue was declined as something which matches the TypeScript vision and removed Needs Proposal This issue needs a plan that clarifies the finer details of how it could be implemented. labels Jan 5, 2021

RyanCavanaugh closed this as completed Jan 5, 2021

microsoft locked as resolved and limited conversation to collaborators Jan 5, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Provide a way to add the '.js' file extension to the end of module specifiers #16577

Provide a way to add the '.js' file extension to the end of module specifiers #16577

quantuminformation commented Jun 16, 2017 •

edited

Loading

cyrilletuzi commented Jun 16, 2017

quantuminformation commented Jun 16, 2017 •

edited

Loading

DanielRosenwasser commented Jun 17, 2017

DanielRosenwasser commented Jun 17, 2017 •

edited

Loading

quantuminformation commented Jun 17, 2017

justinfagnani commented Jun 18, 2017

justinfagnani commented Jun 18, 2017

quantuminformation commented Jun 19, 2017 •

edited

Loading

quantuminformation commented Jun 22, 2017 •

edited

Loading

aluanhaddad commented Aug 9, 2017

AviVahl commented Nov 10, 2017

cyrilletuzi commented Nov 11, 2017

AviVahl commented Nov 11, 2017

cyrilletuzi commented Nov 11, 2017

aluanhaddad commented Nov 11, 2017

AviVahl commented Nov 11, 2017 •

edited

Loading

quantuminformation commented Dec 30, 2017

SalathielGenese commented Dec 30, 2017

matthewp commented Jan 12, 2018

benlesh commented Jan 12, 2018 •

edited

Loading

TheLarkInn commented Jan 12, 2018

FunctionPoint commented Jan 4, 2021 •

edited

Loading

pauldraper commented Jan 4, 2021 •

edited

Loading

FunctionPoint commented Jan 4, 2021 •

edited

Loading

borfast commented Jan 4, 2021

db984 commented Jan 4, 2021 •

edited

Loading

FunctionPoint commented Jan 4, 2021 •

edited

Loading

pauldraper commented Jan 5, 2021 •

edited

Loading

MicahZoltu commented Jan 5, 2021

borfast commented Jan 5, 2021

db984 commented Jan 5, 2021 •

edited

Loading

shicks commented Jan 5, 2021

db984 commented Jan 5, 2021 •

edited

Loading

RyanCavanaugh commented Jan 5, 2021

Provide a way to add the '.js' file extension to the end of module specifiers #16577

Provide a way to add the '.js' file extension to the end of module specifiers #16577

Comments

quantuminformation commented Jun 16, 2017 • edited Loading

cyrilletuzi commented Jun 16, 2017

quantuminformation commented Jun 16, 2017 • edited Loading

DanielRosenwasser commented Jun 17, 2017

DanielRosenwasser commented Jun 17, 2017 • edited Loading

quantuminformation commented Jun 17, 2017

justinfagnani commented Jun 18, 2017

justinfagnani commented Jun 18, 2017

quantuminformation commented Jun 19, 2017 • edited Loading

quantuminformation commented Jun 22, 2017 • edited Loading

aluanhaddad commented Aug 9, 2017

AviVahl commented Nov 10, 2017

cyrilletuzi commented Nov 11, 2017

AviVahl commented Nov 11, 2017

cyrilletuzi commented Nov 11, 2017

aluanhaddad commented Nov 11, 2017

AviVahl commented Nov 11, 2017 • edited Loading

quantuminformation commented Dec 30, 2017

SalathielGenese commented Dec 30, 2017

matthewp commented Jan 12, 2018

benlesh commented Jan 12, 2018 • edited Loading

TheLarkInn commented Jan 12, 2018

FunctionPoint commented Jan 4, 2021 • edited Loading

pauldraper commented Jan 4, 2021 • edited Loading

FunctionPoint commented Jan 4, 2021 • edited Loading

borfast commented Jan 4, 2021

db984 commented Jan 4, 2021 • edited Loading

FunctionPoint commented Jan 4, 2021 • edited Loading

pauldraper commented Jan 5, 2021 • edited Loading

MicahZoltu commented Jan 5, 2021

borfast commented Jan 5, 2021

db984 commented Jan 5, 2021 • edited Loading

shicks commented Jan 5, 2021

db984 commented Jan 5, 2021 • edited Loading

RyanCavanaugh commented Jan 5, 2021

quantuminformation commented Jun 16, 2017 •

edited

Loading

quantuminformation commented Jun 16, 2017 •

edited

Loading

DanielRosenwasser commented Jun 17, 2017 •

edited

Loading

quantuminformation commented Jun 19, 2017 •

edited

Loading

quantuminformation commented Jun 22, 2017 •

edited

Loading

AviVahl commented Nov 11, 2017 •

edited

Loading

benlesh commented Jan 12, 2018 •

edited

Loading

FunctionPoint commented Jan 4, 2021 •

edited

Loading

pauldraper commented Jan 4, 2021 •

edited

Loading

FunctionPoint commented Jan 4, 2021 •

edited

Loading

db984 commented Jan 4, 2021 •

edited

Loading

FunctionPoint commented Jan 4, 2021 •

edited

Loading

pauldraper commented Jan 5, 2021 •

edited

Loading

db984 commented Jan 5, 2021 •

edited

Loading

db984 commented Jan 5, 2021 •

edited

Loading