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

NodeJS/ESM Compliance - use import/export file extensions #4396

Open
sachaw opened this issue Jan 2, 2024 · 9 comments
Open

NodeJS/ESM Compliance - use import/export file extensions #4396

sachaw opened this issue Jan 2, 2024 · 9 comments

Comments

@sachaw
Copy link

sachaw commented Jan 2, 2024

Is your feature request related to a problem? Please describe.

Projects using the modern module resolution algorithm in NodeJS require local import and export statements to suffix the file extension.

Describe the solution you'd like

Forcing projects to use NodeNext as the module resolution setting in each packages tsconfig.json file will enforce this rule.

Additional context

This will be come more and more pertinent as CJS is slowly dying

@dyladan
Copy link
Member

dyladan commented Jan 3, 2024

This requires an update to typescript 5+ which is already on our radar for SDK 2.0 in the next branch #4323

We'll have to consider how to deal with the API since we're not planning to make a major version bump there and upgrading our Typescript version may break some users.

@sachaw
Copy link
Author

sachaw commented Jan 4, 2024

I really think everyone needs to start dropping support for eol Node versions. It's just holding the whole community back.

@dyladan
Copy link
Member

dyladan commented Jan 5, 2024

Unfortunately we're beholden to the needs of our users. If we drop support for old versions it forces our users to upgrade as well. As I said, we're going ahead with this with the SDK 2.0. I'm not saying we won't move forward with the API as well, but it needs to be thoroughly considered.

Unfortunately, we have no real way of knowing:

  1. What version of node our users are on
  2. What version of typescript our users are on
  3. If our users would upgrade the above if required by us
  4. How painful that upgrade would be
  5. How many users would either drop otel or stay on old unsupported versions

Once 2.0 is released, we may have a better idea of the answers to the above questions depending on the adoption rate. If users quickly migrate from the 1.x line to the 2.x line, we will know they are at least on the runtimes supported by that and it will give us some idea as to the safety of migrating the API in a minor version release.

@gajus
Copy link

gajus commented Jan 23, 2024

I believe this to be related #4437

Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the stale label Mar 25, 2024
@jaydenseric
Copy link

Not stale.

@github-actions github-actions bot removed the stale label Apr 8, 2024
Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

@github-actions github-actions bot added the stale label Jun 17, 2024
@martabitbrain
Copy link

This is still a thing that should be considered.

Copy link

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

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

No branches or pull requests

6 participants