Support list of files/directories to be ignored by fmt and lint via a .denoignore file

[retog]

I would like to be able to specify directories and/or file patterns that shall be ignored by deno fmt and deno lint. This could be achieved with a .denoignore file similar to .gitignore.

Motivation:

• It's not uncommon for applications to store data in or below the current working directory, which during development is often where the sources are. Such files do not need to be formatted.
• Bundled files to be served to browsers might also be generated to reside near the sources, Such files should be ignored by deno lint.

[GJZwiers]

You can include/exclude directories from deno fmt or deno lint with a config file if needed, see the manual page.

[retog]

@GJZwiers, you're right and with the automatic lookup planned for the upcoming releases this will be quite close to the desired feature. I think .denoignore would however be an easier approach.

[bartlomieju]

@GJZwiers is right, the configuration file is the way to do it, but you can also add // deno-lint-ignore-file and // deno-fmt-ignore-file directives at the top of the files to notify the tools that they shouldn't consider these files.

I think .denoignore would however be an easier approach.

This won't happen, we will support only a single configuration file and don't intend to add custom ignore files or consider .gitignore file for this purpose.

[retog]

@bartlomieju for a package.json style global config you have to read a manual, .gitignore and .dockerignore style files by contrast are pretty self-explanatory.

Besides that adding "// deno-fmt-ignore-file" renders the json invalid it is not an option if the tool aggregates or caches JSON data from other sources.

Also, does the bundle feature support adding such a header? The result of bundling generates a lot of deno lint warnings.

But you seem to be in a position to know what the community will and will not support and what its intentions are. To me, this doesn't sound like the open, welcoming, diverse, inclusive, and healthy community the code of conduct wants to achieve. What gives you this sense of authority in the matter? Has this been previously discussed? Giving references would help me understand your answer.

[bartlomieju]

@bartlomieju for a package.json style global config you have to read a manual, .gitignore and .dockerignore style files by contrast are pretty self-explanatory.

Besides that adding "// deno-fmt-ignore-file" renders the json invalid it is not an option if the tool aggregates or caches JSON data from other sources.

That's a good point, indeed you can't add a comment to a plain JSON file.

Also, does the bundle feature support adding such a header? The result of bundling generates a lot of deno lint warnings.

It doesn't do that automatically, but you can add it after bundling (though I see no reason not to add them automatically). Bundled files are artifacts produced in a build step and such files are not usually linter/formatted afterwards. Do you have a use case in mind where you want to lint bundled file?

But you seem to be in a position to know what the community will and will not support and what its intentions are. To me, this doesn't sound like the open, welcoming, diverse, inclusive, and healthy community the code of conduct wants to achieve. What gives you this sense of authority in the matter? Has this been previously discussed? Giving references would help me understand your answer.

If community wants to use .denoignore file for 3rd party tools then it's completely fine for me. I stated that deno itself will not support such file (deno doesn't even lookup tsconfig.json/deno.json/deno.jsonc automatically as of now and we are being very conservative to introduce this feature) and Deno tries to be minimalistic in terms of adding dotfiles for multiple purposes. I'm speaking from a position of maintainer of the project here. Automatic lookup of files was discussed in #6805 and in #4459.

[retog]

It doesn't do that automatically, but you can add it after bundling (though I see no reason not to add them automatically). Bundled files are artifacts produced in a build step and such files are not usually linter/formatted afterwards. Do you have a use case in mind where you want to lint bundled file?

I exactly don't want to lint them. Consider a simple project structure for a web-app.

/README.md
/build.ts
/module1.ts
/module2.ts
/index.html
/images/logo.png
/js/bundle.js
/.gitignore

The generated /js/bundle-js should not be linted. Currently, it is linted when running deno lint without additional arguments. A huge amount of pointless linting errors might also appear in VSCode which has no way to know that this file is generated.

I see that .denoignore has indeed already been discussed in #6805, you rejected it "as it's against conventions in CLI that do not pick up any files automatically". But now the manual promises exactly that "an automatic lookup of this file is planned for the upcoming releases", so the choice is really between asking users to study the manual and write a configuration file or to provide an intuitive way to make sure some files are ignored by the deno tools.

One can live without .denoignore, one could also live without .gitignore. But both files can make life easier when dealing with simple project structures or with tools that happen to add additional files alongside the source files. I find it hard to see the situation where a .denoignore file would create confusion, but many situations where it would make things easier.

[dsherret]

I would like to be able to specify directories and/or file patterns that shall be ignored by deno fmt and deno lint. This could be achieved with a .denoignore file similar to .gitignore.

As mentioned, this is already supported via a config file by doing deno fmt --config deno.json. In the future, the plan is for a file at deno.json will be automatically picked up so it doesn't need to be explicitly provided.

Alternatively, files/directories may be ignored on the cli by specifying an --ignore flag.

The generated /js/bundle-js should not be linted. Currently, it is linted when running deno lint without additional arguments. A huge amount of pointless linting errors might also appear in VSCode which has no way to know that this file is generated.

See the deno.config option in vscode: https://github.com/denoland/vscode_deno#configuration

Also, does the bundle feature support adding such a header? The result of bundling generates a lot of deno lint warnings.

You can add the output of the bundle command to the deno.json. Alternatively, when creating the bundle you can prepend // deno-fmt-ignore-file and // deno-lint-ignore-file to the output in your shell. Edit: Actually, this would break sourcemaps. See Bartek's comment below for a solution, but you could also add these to be ignored in a config file.

so the choice is really between asking users to study the manual and write a configuration file or to provide an intuitive way to make sure some files are ignored by the deno tools.

.denoignore would not be intuitive in my opinion and would still require looking it up in the manual and then provide more confusion about whether a deno.json should be used or .denoignore. Also, would .denoignore ignore certain files from running via deno run? What if someone wanted to ignore files only for formatting and not for linting? Right now a deno.json solves this.

One can live without .denoignore, one could also live without .gitignore. But both files can make life easier when dealing with simple project structures or with tools that happen to add additional files alongside the source files. I find it hard to see the situation where a .denoignore file would create confusion, but many situations where it would make things easier.

I've looked into implementing directory based files such as .denoignore before. They are complicated to support and it slows down collection of files. An implementation of this in Rust is available here for .gitignore (https://github.com/nathankleyn/gitignore.rs). Although they may provide some convenience, there are already the other two solutions mentioned above that work. Also, we want to avoid multiple configuration files (even getting --config deno.json in was a challenge).

The convenience of the current configuration file will improve once deno.json files are automatically picked up.

Due to the complexity of this issue and the other solutions that exist, it's not something that we want to maintain as maintainers. For that reason, I'm going to close this issue.

[bartlomieju]

@retog I opened #12949 to add ignore directives to bundled code.

[retog]

I hate seeing deno losing its simplicity. This isn't mainly about having to write 12-15 lines of config rather than just 1: By effectively coercing users to put a prominent deno.json in the root of their projects, this encourages setting all kind of project specific options rather than relying on deno's sensible default. Sure, #12949 is great and will obsolete many ignore directives, unfortunately I think we will still see many deno json files that have to be created just to ignore a file or directory.

So while dismissing this proposal sounds like reducing configuration options, it effectively promoted full-fledged project specific configurations.

[riderx]

I just found this tread as I needed to ignore NPM folder created by DNT lib.
The Deno JSON was already in the project, added only 1 line to it, no fucking new file for just one ignore!
A bliss thanks Deno team for standing for your idea, it's paying off !