Level up DX

[dustinleblanc]

After a little bit of time contributing to Lando in small ways, there are a few ways I think we could improve the developer experience which should pay off in spades for offloading development burden from core maintainers. A few of the things I think would be useful.

• [x] A .node-version file so folks can use things like nodenv to peg their node version for development
• [ ] Ensuring the entire test suite can run in any environment (can we do some dogfooding and somehow run inside a container?)
• [x] A .editorconfig file so that folks can get some automatic code style help. I know we already check code style with a linter, but every little bit helps imo.
• [ ] A dev-mode plugin or some other way to tell Lando it is running in Dev mode. Set Some defaults and do some stuff that is useful for developers and not end users. Things like using local images rather than pulling from docker hub, more verbose logging, etc
• [x] Switch from jscs and jshint to eslint. JSCS seems to throw odd errors, and it has been deprecated in favor of eslint (see https://medium.com/@markelog/jscs-end-of-the-line-bc9bf0b3fdb2)
• [ ] Fix bats tests so they can actually run on developer machines and/or in CI. They should either run or be removed

what say ye merry ladies and gents?

[uberhacker]

I'm all for improvements. The problem with .editorconfig and why you cannot commit it in the repo is because developers tend to prefer different editors/IDEs. Unless, of course, you require all the devs to use a specific editor/IDE. What would be really awesome is if you could detect which editor/IDE the developer is using and then download the appropriate .editorconfig from https://github.com/editorconfig.

[dmsmidt]

We could work with .editorconfig.example.sublime etc. or something. And gitignore .editorconfig. So provide the example for multiple much used IDE's.

[dustinleblanc]

@uberhacker isn't .editorconfig designed to be IDE/editor agnostic?

as in the file is one format, and different editors are supposed to implement a plugin to consume the declared styles. I believe that is 100% the point of .editorconfig

[dmsmidt]

I currently use yarn to manage my deps, so would prefer a yarn.lock instead of a package-lock.json. Any more takers?

[dustinleblanc]

# top-most EditorConfig file
root = true

# Unix-style newlines with a newline ending every file
[*]
end_of_line = lf
insert_final_newline = true
charset = utf-8

[*.js]
indent_style = space
indent_size = 2

should be sufficient for all editors to pick up on

[dustinleblanc]

@dmsmidt Yarn is great, though I am wavering a bit lately on which lockfile to use given that NPM now has them. I have no preference and would rather use what makes the majority of maintainers happy there.

[uberhacker]

@dustinleblanc: You are right about that. "EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs.". I guess I worded it incorrectly. Since different editors require plugins in order to import the .editorconfig settings, we would need to make sure each editor/IDE has the appropriate plugin installed.

[dustinleblanc]

@uberhacker I don't think you'd need to ensure anything, its more of an incremental improvement thing. Providing the file as part of the repo makes things easier and causes no extra problems. Its an opt-in helper. The make-or-break comes when the test suite / linter is run. That is where enforcement happens. This is less about enforcement, and more about improving the experience for developers who can make use of some helpful tools.

[uberhacker]

@dustinleblanc: Fair enough. I'll continue on with my day. :)

[pirog]

Totally plus +1 on the .editorconfig, definitely good to have along with the js linting and standards files that are already in there.

Regarding locking down the developer experience (i know @uberhacker will be annoyed by this suggestion but...) we could always use lando to develop lando.

[dustinleblanc]

Working on exactly that 💃

[pirog]

[dustinleblanc]

added a few more items to the list based on issues I am running into. We might want to focus on this more for 3.1 as per what @pirog was saying in slack today. My approach in #602 has surfaced a few linting issues because I am jumping whole hog into ES6 land, and since jscs is deprecated, it is proving to be interesting to figure out how to fix them.

FYI at @pirog, I also got Lando-in-Lando to run, and I would love to use that specifically for running the 'linux client' tests so to speak, but there are probably more t's to cross and i's to dot to make sure that works right

[dustinleblanc]

I'm at 3/5 on current items