Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Level up DX #620

Closed
dustinleblanc opened this issue Jan 5, 2018 · 14 comments

Comments

Projects
None yet
4 participants
@dustinleblanc
Copy link
Member

commented Jan 5, 2018

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.

  • 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?)
  • 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
  • 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

This comment has been minimized.

Copy link
Contributor

commented Jan 5, 2018

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

This comment has been minimized.

Copy link

commented Jan 5, 2018

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

@dustinleblanc

This comment has been minimized.

Copy link
Member Author

commented Jan 5, 2018

@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

This comment has been minimized.

Copy link

commented Jan 5, 2018

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

@dustinleblanc

This comment has been minimized.

Copy link
Member Author

commented Jan 5, 2018

# 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

This comment has been minimized.

Copy link
Member Author

commented Jan 5, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 5, 2018

@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

This comment has been minimized.

Copy link
Member Author

commented Jan 5, 2018

@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

This comment has been minimized.

Copy link
Contributor

commented Jan 5, 2018

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

@pirog

This comment has been minimized.

Copy link
Member

commented Jan 5, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Jan 5, 2018

Working on exactly that 💃

@pirog

This comment has been minimized.

Copy link
Member

commented Jan 5, 2018

image

@dustinleblanc

This comment has been minimized.

Copy link
Member Author

commented Jan 9, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Jan 10, 2018

I'm at 3/5 on current items

pirog added a commit that referenced this issue Jan 12, 2018

pirog added a commit that referenced this issue Jan 16, 2018

pirog added a commit that referenced this issue Jan 17, 2018

pirog added a commit that referenced this issue Jan 17, 2018

pirog added a commit that referenced this issue Jan 20, 2018

pirog added a commit that referenced this issue Jan 20, 2018

pirog added a commit that referenced this issue Jan 20, 2018

pirog added a commit that referenced this issue Jan 26, 2018

pirog added a commit that referenced this issue Jan 26, 2018

pirog added a commit that referenced this issue Jan 28, 2018

pirog added a commit that referenced this issue Jan 29, 2018

pirog added a commit that referenced this issue Jan 29, 2018

pirog added a commit that referenced this issue Jan 29, 2018

pirog added a commit that referenced this issue Jan 29, 2018

pirog added a commit that referenced this issue Jan 29, 2018

pirog added a commit that referenced this issue Jan 29, 2018

pirog added a commit that referenced this issue Jan 29, 2018

pirog added a commit that referenced this issue Feb 7, 2018

pirog added a commit that referenced this issue Feb 8, 2018

@dustinleblanc dustinleblanc added this to the 3.0.0 milestone Feb 22, 2018

@pirog pirog closed this Mar 14, 2018

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.