New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
The documented CJS import doesn't work with typescript #133
Comments
you should be able to just |
If you have suggestions for other import conditions, that would be awesome - please submit a PR showing how you consume it. On more complex stacks the imports are fairly automatic and match the simple import cases shown. The bundlers in those stacks are able to decipher what to do. |
Thanks for your fast reply @aricart but the CommonJS + TypeScript story doesn't go like that...
Anyway, is there a strong reason why you can't setup this library in a more standard way? I think |
Sure, I'll have a look. What is your environemnt then? |
webstorm - I'll do a simple script to create an environment in react. |
Okay I had a look at the linked issue and the library structure.
|
so the typings are processed by the IDE normally - otherwise, the completions wouldn't be able to figure out the structure - and open the .ts.d files, here's a simple repo - yes it doesn't install the typescript machinery, but it does create a react project, and when started everything works. So at least for top of the world react - it seems to do the right thing. Perhaps you can help me expand on this and verify on your side. See https://github.com/aricart/npmscripts In my case clicking on the connect function correctly opens |
@henrify - just really want to get to the bottom of this - because previous bundles were problematic - these run as is - and indeed I suspect that somewhere there's some issue with WebPack and typescript compilers - check out this note as well to make sure we are in sync - https://github.com/nats-io/nats.ws/blob/main/developer_notes.md#older-typescript-compiler |
@aricart that is the expected behavior. When importing from "nats.ws" the d.ts typings are found just fine, but building / bundling for CommonJS fails, because the "nats.ws" is resolves to ESM module, and ESM modules cannot be used from CommonJS. |
are you running in the server? |
Indeed the react project is javascript - let me create a version that uses typescript, but I would expect the bundler to do exactly what it did. |
Regarding the environment: If you mean WebStorm as in the JetBrains IDE, then that is not really your "environment "in the meaning and context of bundling/building -- WebStorm delegates to something else under the hood to do the build (tsc, webpack, etc.), and what that something else is determines whether Regarding your new test project that imports successfully: create-react-app has just (couple of weeks ago?) had a major release (v5) and it is possible that they have changed the build / bundling stack so that v5 can import ESM modules (but 99.9% of existing projects still use v4 which does not work with ESM modules). Your test project should probably use the older and dominant v4 to make it relevant for existing projects (but of course testing also with v5 would be good). |
@henrify - I did some more digging with version 4 - never mind that you cannot run create-react-app version 4.0.3 - the createReactApp.js effectively will refuse to run if the 5 is available - regardless of whether the global is installed or not - I bypassed this issue by editing the script. checkForLatestVersion()
.catch(() => {
try {
return execSync('npm view create-react-app version').toString().trim();
} catch (e) {
return null;
}
})
.then(latest => {
if (latest && semver.lt(packageJson.version, latest)) {
console.log();
console.error(
chalk.yellow(
`You are running \`create-react-app\` ${packageJson.version}, which is behind the latest release (${latest}).\n\n` +
'We no longer support global installation of Create React App.'
)
);
console.log();
console.log(
'Please remove any global installs with one of the following commands:\n' +
'- npm uninstall -g create-react-app\n' +
'- yarn global remove create-react-app'
);
console.log();
console.log(
'The latest instructions for creating a new app can be found here:\n' +
'https://create-react-app.dev/docs/getting-started/'
);
console.log();
process.exit(1);
} else {
createApp(
projectName,
program.verbose,
program.scriptsVersion,
program.template,
program.useNpm,
program.usePnp
);
}
}); I was able to run it - note it is not doing typescript - I didn't go there because that further adds another layer - but at the react level, the current bundling for nats.ws is accessible to react 4 and 5 |
Hmm, what was the exact import statement you used? |
import React, { useEffect, useState } from "react";
import { connect } from "nats.ws";
... |
Best guess... With Javascript, the 'import' statement is kept as is, which means that you are using browser/node native ESM support, and therefore loading the ESM module works. With TypeScript, the 'import' statement is transpiled to CommonJS 'require()' call, which tries to load the same ESM module file, and therefore fails. Try with typescript? (it's just |
will do - but realize again the old create app is not supported anymore, and yes tsc and bundlers have received updates. Going the other way is not correct - I believe that if you do the "expanded" import where you point it at the file, it will do the right thing for you. |
I believe something like this can be written in the package.json to add typing automatically:
Instead of the current:
This would require creating an index.d.ts file, but tsc can do this automatically. |
Hi, the docs start with saying that CommonJS version is rooted at "./cjs/nats.js", however, that cannot be imported directly from TypeScript, as there are no typings.
For CommonJS + TypeScript, the only import I got to work was:
import {connect, NatsConnection} from "nats.ws/lib/src/mod.js";
Is that the correct way?
Plus obviously it would be good to fix the basics -- use a more standard package layout that is easy and obvious to import, and document clearly how to import for modern stuff for those who still fail at the easy and obvious (currently the "importing the module" section of the docs only talks about using a <script> tag, which admittedly was a great and popular way in the 1990s and even early 2000s, but in 2022 not so much anymore).
The text was updated successfully, but these errors were encountered: