171–180 of 214 posts
The root is the right place for project-wide settings. GitHub and other tools should do what ls does and hide dotfiles by default. That’s why they are dotfiles. Other project-unrelated config/metadata should follow the .git example and use dotfile config files, preferably yaml or something similar (not json, as it does not support comments).
I 100% agree on this. But it's been pretty hilarious on how obstinate tool makers are about changing to Python's new pyproject.toml [1] Python packaging is a bit of a mess already, so when I recently started a new small package I wanted to choose tooling that would not clutter, but a fair amount of tool makers were reluctant to allow code into their repo that would use the unified toml rather than a ton of separate f…
That link is a really good read. Better than TFA, tbh. And also particularly well written > An interesting side-effect of PEP 518 trying to introduce a standard file that all projects should (eventually) have is that non-build development tools realized they now had a file where they could put their own configuration. I say this is interesting because originally PEP 518 disallowed this, but people chose to ignore thi…
If it's about "cleaning up" before committing, a single script that moves files back and forth from project root to a .config path might also be an option...
Earlier quoted context omitted.
requirements.txt has a lot of deficiencies for package management (compare to the various features Yarn or Cargo offer). The biggest weakness is transitive dependency locking: even if you specify the exact version of the dependencies you want, Pip can still resolve to a different version of their dependencies, and even then there’s no verification that the content matches what is expected beyond the version number (o…
>The biggest weakness is transitive dependency locking: even if you specify the exact version of the dependencies you want, Pip can still resolve to a different version of their dependencies Isn't that what pip freeze is for?
How conscientious. And yup, conventions like this work well Linux and BSD's. To note ~/.config for many configs These days you see this happening inside of .github/, where configs related to gh repos and actions go. If tooling authors started universally recognizing .config/ as a directory where we could keep stuff, the root could be super clean. How about just one file, across languages / CI tools / etc? a "project.…
One directory, maybe .config, seems like a good idea. One file is asking for trouble. All it takes is someone writing their first command-line app mixing up > and >> and suddenly the user's config for every tool they use is gone.
Earlier quoted context omitted.
Or hide/collapse dotfiles like the ls command does.
Putting them in .config is something to work toward in the long term, but I like this as an immediate fix. A possible UX could be a single entry at the bottom of the repo root listing with "+ 6 hidden files, click here to show", that then expands out to to reveal the full listing when clicked. Edit to add— someone suggests this on the linked issue, and it is mentioned as a concern that auto-hiding the files could lea…
Earlier quoted context omitted.
`ls` is probably the most important place they're hidden, but the Mac OS Finder honors this convention too.
i much prefer them to be hidden by default. i know they are there, but rarely do i need them. especially in something like `for i in $(ls -1)` type of commands. if i need them `alias 'lla = ls -la'`, 'alias 'la = ls -a'` are faves to now see what i'm looking for quickly
for i in *Earlier quoted context omitted.
also don't forget: - .eslintrc.json to configure ESLint - .prettierignore because it tries to format package-lock.json - prettier.config.json - npm/yarn and package.json + node_modules - .nvmrc to pin your node version - storybook - renovate to update dependencies - .editorconfig to ignore node_modules - mocha for testing and .mochaarc.js - stylelint and .stylelintrc.json + .stylelintignore And maybe throw in Jest, t…
Maybe it’s just because I was raised on this ecosystem, but in my opinion the sheer amount of incredible functionality you get from all this tooling (at the low price of $0!) is worth 10-15 set-and-forgot files that don’t even show up when you type ls.
Earlier quoted context omitted.
> The same argument is made for not adhering to the XDG spec for user configuration files I think it's a fundamental difference in that the project repo should be self-contained and "owned", whereas arbitrary software I run really shouldn't be putting files in my home directory. In a software repo, anything inside it belongs to the project.
I think there are similarities -- the project's root is the project's, so why does eg the Travis CI system get to insist on having a config file sat in the project root?
Just like the gitlab-ci.yml, it handles things related to the whole repo, it basically runs a script in the root of the repo anyway.
Sure, supporting other paths is useful (eg. in case of a monorepo), but this default seems sane. Though I'm interested in where others move it, and why.