Skip to content
This repository has been archived by the owner on Jul 16, 2024. It is now read-only.

opCodes/configError"' has no exported member 'OP_SOURCE_UNAVAILABLE'. etc #324

Closed
leighman opened this issue Mar 29, 2023 · 4 comments
Closed

Comments

@leighman
Copy link

leighman commented Mar 29, 2023

🐛 Bug report

Current Behavior

When installing I get a number of TS compilation errors

node_modules/@effect/io/Config/Error.d.ts:94:28 - error TS2694: Namespace '"/blah/node_modules/@effect/io/internal_effect_untraced/opCodes/configError"' has no exported member 'OP_SOURCE_UNAVAILABLE'.

94     readonly _tag: OpCodes.OP_SOURCE_UNAVAILABLE;

Expected behavior

I would expect no compilation errors from the library

Your environment

Didn't try below 0.6.0

Software Version(s)
@effect/schema v0.6.0-v0.8.0
TypeScript 4.9.5
@gcanti gcanti transferred this issue from Effect-TS/schema Mar 29, 2023
@IMax153
Copy link
Member

IMax153 commented Mar 29, 2023

@mikearnaldi - given that our build process in-lines the op codes anyways, we should probably just consider removing op codes entirely.

@IMax153
Copy link
Member

IMax153 commented Mar 31, 2023

@leighman - I believe this should be closed by 985dca4 once released. Going to close this issue. Thanks for the report!

@IMax153 IMax153 closed this as completed Mar 31, 2023
@stazz
Copy link

stazz commented Mar 31, 2023

@IMax153 Would it make sense to add a step into CI/CD pipeline, which would try to compile a simple TypeScript file, which would just import the .d.ts code produced by compilation of the source code in this repo? That would help to avoid similar errors in the future. At least I use similar approach in my own libraries, and it has helped me catching few similar errors to this one.

I can open separate ticket for that if you think that's good idea. Maybe even make a PR :)

@IMax153
Copy link
Member

IMax153 commented Mar 31, 2023

Thanks @stazz! Personally I don't think it's 100% necessary and would probably end up complicating our CI pipeline. We're pretty careful about only exposing things from the library that are going to end up in the declaration files.

That being said - I'll leave it up to @mikearnaldi for the final word.

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

No branches or pull requests

3 participants