Skip to content
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

Unable to leverage universal-cookie, react-cookie, and universal-cookie express with NodeNext module resolution #471

Closed
corbin-mosher opened this issue Mar 29, 2024 · 6 comments

Comments

@corbin-mosher
Copy link

We would like to use the universal-cookie dependencies in our packages that are fully ESM rather than CommonJS and leverage TypeScript as our build tool. The resulting packages are used by some Node applications as well as browser based applications generated with Vite.

However, the type definitions for the libraries do not seem to work with the NodeNext moduleResolution for TypeScript's tsconfig.

Here is a minimal reproduction of the issue: (sandbox link)
Screenshot 2024-03-29 at 9 29 45 AM

I believe the issue could maybe be similar to this, but maybe not precisely. I am not super familiar with the challenges of exposing a package as a maintainer for ESM, CJS, and UMD consumption. So I am not 100% clear on how to alter the universal-cookie project to structure its types correctly for all three to work.

Thoughts on if this is something that can be patched?

@eXon
Copy link
Collaborator

eXon commented Mar 31, 2024

Hi @corbin-mosher ,

The TypeScript types seem to be not working with your tsconfig configuration. I'm trying to dig deeper to find a solution to why, this is very unexpected.

@corbin-mosher
Copy link
Author

corbin-mosher commented Mar 31, 2024

@eXon, yeah, it is very confusing.

I even tried cloning the cookies project and running it through my normal build pattern and I have the same type issue.

The only way I have gotten it to work is to also export Cookies as a named export, not just the default. For some reason, with NodeNext tsconfig there is a struggle with this declared Cookies class, but only when its the default export 🙃

There have been one or two more npm packages that have had similar issues for me with default exports and NodeNext, so I am likely going to just stick with Bundler+ESNext for now and continue using unbuild (rollup) to handle build commands.

I am super curious though to learn what causes this hangup when building and resolving things purely with tsc+tsconfig. My guess is that there is some not very well known "specification" around ESM and types we are missing that has become required with the latest moduleResolution 🤷

eXon added a commit that referenced this issue Mar 31, 2024
* Use mts extension

* Also fix import/export in typedef

* Remove clog

* Fix formatting
@eXon
Copy link
Collaborator

eXon commented Mar 31, 2024

@corbin-mosher This is fixed in 7.1.2, let me know if it works for you

@eXon eXon closed this as completed Mar 31, 2024
@corbin-mosher
Copy link
Author

@eXon, thanks! Types are working as expected now with NodeNext for moduleResolution in tsconfig.

I really appreciate the quick help.

@corbin-mosher
Copy link
Author

@eXon, now that I have had time to sit down with this further, it seems to me that the post build script plan might need some alterations.

It is impacting imports of external dependencies as well. For example, in react-cookies the type file for CookieProvider is altered from:

import * as React from 'react';
import Cookies from 'universal-cookie';
import { ReactCookieProps } from './types';
export default class CookiesProvider extends React.Component<ReactCookieProps, any> {
    cookies: Cookies;
    constructor(props: ReactCookieProps);
    render(): React.JSX.Element;
}

to

import * as React from 'react.d.mts';
import Cookies from 'universal-cookie.d.mts';
import { ReactCookieProps } from './types.d.mts';
export default class CookiesProvider extends React.Component<ReactCookieProps, any> {
    cookies: Cookies;
    constructor(props: ReactCookieProps);
    render(): React.JSX.Element;
}

Its possible that the change on line 3 is OK since it is referencing a file directly. But I think the changes on line 1 & 2 would cause issues. Let me know what you think.

@eXon
Copy link
Collaborator

eXon commented Apr 1, 2024

@corbin-mosher You're right! I've fixed the regex, let me know if 7.1.4 works

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants