-
Notifications
You must be signed in to change notification settings - Fork 2.5k
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
Fix magic export deprecation messaging #4661
Conversation
🦋 Changeset detectedLatest commit: 72a22c9 The changes in this PR will be included in the next version bump. This PR includes changesets to release 16 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
It would be a shame to revert #3284 imo, as we would lose TS deprecations that way, which are another added benefit imo. Since this only seems to be impacting ESM builds, can we at least keep CJS & TS?
This could be fixed by removing it from the specific
So if we can update the ESM imports properly, we can keep these I guess? @brophdawg11 What if we do the following instead? import { ${symbol} as ${moduleName}_${symbol} } from '${packageName}';\n
/** @deprecated Import `${symbol}` from `${packageName}` instead. *\n
const ${symbol} = warn(${moduleName}_${symbol}, getDeprecatedMessage('${symbol}', '${packageName}'));\n So that we have import { createCookie as node_createCookie } from '@remix-run/node';
/** @deprecated Import `createCookie` from `@remix-run/node` instead. */
const createCookie = warn(node_createCookie, getDeprecatedMessage('createCookie', '@remix-run/node')); I'm happy to create a PR with the changes I suggested. |
@MichaelDeBoey Definitely open to suggestions, this was just the quick fix towards getting I like the idea of keeping the TS deprecation warnings. I'm not sure if this would work for ESM, since the import is used and therefore I don't think qualifies for tree-shaking:
Let me see about keeping the types. I think I lean towards keeping the CJS/ESM approaches the same to avoid unintended behavioral differences, but curious what others think there too. I did the |
What about changing it to the following? import node from '@remix-run/node';
/** @deprecated Import `createCookie` from `@remix-run/node` instead. */
const createCookie = warn(node.createCookie, getDeprecatedMessage('createCookie', '@remix-run/node'));
This would mean we would loose the benefit of the deprecated JSDoc on all these functions
Since our React component are function components, it's basically the same as a normal function, no? |
7774492
to
229503e
Compare
@MichaelDeBoey As soon as we reference anything from I added back in the TS deprecations in 5083780 👍 Then @jacob-ebey had a better idea of how we can do this warning at build-time via an I think the React component was potentially from |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Even though we would loose the extra JSDoc deprecation warnings in your IDE, if there's no other reason to make sure we can still three-shake in ESM, I like the idea of esbuild
throwing a warning 👍
let cjsModule = camelCase(packageName.slice("@remix-run/".length)); | ||
cjsContents += `var ${cjsModule} = require('${packageName}');\n`; | ||
for (let symbol of magicExports.values) { | ||
cjsContents += | ||
`Object.defineProperty(exports, '${symbol}', {\n` + | ||
" enumerable: true,\n" + | ||
` get: function () { return ${cjsModule}.${symbol}; }\n` + | ||
"});\n"; | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can keep the JSDoc deprecation here as well to have an extra IDE warning?
let cjsModule = camelCase(packageName.slice("@remix-run/".length)); | |
cjsContents += `var ${cjsModule} = require('${packageName}');\n`; | |
for (let symbol of magicExports.values) { | |
cjsContents += | |
`Object.defineProperty(exports, '${symbol}', {\n` + | |
" enumerable: true,\n" + | |
` get: function () { return ${cjsModule}.${symbol}; }\n` + | |
"});\n"; | |
} | |
cjsContents += `var ${moduleName} = require('${packageName}');\n`; | |
cjsContents += magicExports.values | |
.map( | |
(symbol) => | |
`/** @deprecated Import \`${symbol}\` from \`${packageName}\` instead. */\n` + | |
`exports.${symbol} = ${symbol};\n` | |
) | |
.join("\n"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@MichaelDeBoey I'm having trouble actually seeing this JSDoc warning anywhere in my VSCode IDE 🤔
If I create a fresh Remix JS project, VSCode still shows me the deprecation from our .d.ts
file in node_modules/remix
in my .jsx
files:
If I build with this JSDoc comment included and I remove the .d.ts
file, then I don't see the deprecation, and I just see the JSDoc from the internal definition of the method, not the JSDoc of the re-exported version from remix
:
So for now I'm going to merge this without the CJS JSDoc updates since I can't quite prove that they're picked up. It does seem that even in non-TS projects, at least VScode will pick up our .d.ts
deprecation warning.
If we can find specific cases where the JSDoc enhances the DX I'm all for a subsequent PR before we release 1.8.0
stable, but for now I want to get 1.8.0-pre.1
out so folks can help test the new @remix-run/router
work inside of Remix 👍
@brophdawg11 When doing the following:
If you want, I can create a PR against |
* Revert "Deprecate all functions & types exported from `magicExports` (#3284)" This reverts commit 848d8b0. * Single deprecation warning per remix index file * Revert "Single deprecation warning per remix index file" This reverts commit 7774492. * Add back in TS deprecation typings * Warn on deprecated remix imports via esbuild plugin * add chgangeset
This reverts #3284 due to a few unforeseen issues:
const getDeprecatedMessage
andconst warn
which caused build failuresInstead this goes back to the old direct-export approach for the CJS/ESM modules, but keeps the annotated TS
@deprecated
exports. Then we added a newesbuild
plugin that detects imports fromremix
at build time and logs out a warning for the problematic file:Testing
npx [email protected]
import { Link } from "remix"
REMIX_LOCAL_BUILD_DIRECTORY=../playgrounds/my-remix-app yarn build
npx remix setup node
npm run dev
should show you a build time warning for the deprecated import