denoland / deno_config Goto Github PK

To better support workspaces, we need to compute various configurations like linter, formatter, test and TSC settings.

We need an API that given the specifier will return correct setting, eg.:

get_lint_options_for_specifier(specifier: &Url) -> Result<LintConfig, AnyError>;

get_compiler_options_for_specifier(specifier: &Url) -> Result<TsConfig, AnyError>;

get_fmt_options_for_specifier(specifier: &Url) -> Result<FmtConfig, AnyError>;

get_test_options_for_specifier(specifier: &Url) -> Result<TestConfig, AnyError>;

For format and lint we want to collect all specifiers that are to be
linted/formatted, and then group them based on the configuration that should be
applied to them.

We should work on include and exclude configurations first.

This will be applied to all tools using configuration and it makes little sense to resolving
compiler options/lint rules/formatter rules/etc.

Eg. if you omit test.include we still need to get all the files ending with .test.ts and _test.ts.

Similarly if you omit fmt.exclude we still want to exclude .git and node_modules/ etc.

So far we landed on these options supported in workspace and package settings:

Doesn't suit include-by-default semantics. If remote URLs aren't applicable to the exclude/include they should just pass through. I've had to bypass this in denoland/deno@701525a.

Make this true instead.

1. Config is a subset of workspace.
2. I'd like to make more APIs on config private to force people to access them through the workspace instead to reduce bugs.

Because it has information about the start directory. This will make it less confusing in the LSP.

Example:

{
  "workspaces": ["packages/*"] // or whatever it is
}

Not sure if this is handled, but should there be a way to opt-out of a top level exclude? Should this work?

{
  "publish": {
    "include": "./dist"
  },
  "exclude": ["./dist"]
}

Someone may want to exclude the dist folder from the lsp, fmt, lint, etc, but then include it for publishing because it contains a build of the package.

Originally posted by @dsherret in #34 (comment)