Skip to content
This repository has been archived by the owner on Aug 23, 2018. It is now read-only.

Prevent publishing when types in public type signatures are unexposed #277

Open
rtfeldman opened this issue Jul 11, 2017 · 4 comments
Open
Labels

Comments

@rtfeldman
Copy link

elm-css has a lot of PRs like this: rtfeldman/elm-css#290

The basic problem is that I can expose a function like Int -> Foo -> String and forget to expose Foo. This means users of the package can partially apply this function and end up with a Foo -> String function that they cannot annotate, because Foo is not exposed.

It would be great if elm-package could give an error on publish if a public type signature incorporates a non-public type.

@process-bot
Copy link

Thanks for the issue! Make sure it satisfies this checklist. My human colleagues will appreciate it!

Here is what to expect next, and if anyone wants to comment, keep these things in mind.

@rtfeldman rtfeldman changed the title Warning when values in public type signatures are unexposed Prevent publishing when types in public type signatures are unexposed Jul 11, 2017
@evancz evancz added the problem label Jul 11, 2017
@evancz
Copy link
Contributor

evancz commented Jul 11, 2017

Nice suggestion, I'll see if I can add that in as well!

@laszlopandy
Copy link
Member

laszlopandy commented Jul 12, 2017

For reference TypeScript has this check and it looks like this:
Example.ts(12,24): error TS4060: Return type of exported function has or is using private name 'ExampleType'.
Or:
Example.ts(12,24): error TS4078: Parameter 'a' of exported function has or is using private name 'ExampleType'.

@ianmackenzie
Copy link

What exactly should it mean for a type to be exposed? Exposed directly from the module in which it is defined? Exposed via an alias in another module? (Does the alias have to have the same name as the original type?) I've added an example in #281.

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

No branches or pull requests

5 participants