Migrating from 6 to 7

History of Jeet's Versioning

Skip to "Migration Strategy" if you're not interested in this part.

Up until 7.0.0, Jeet was all over the place with versioning.

Timeline of recent events:

0. 1.0.0--6.1.2 I was a newb and didn't fully appreciate semver. I fell into the "marketing" trap. Here is a good talk on the subject.
1. 6.1.2 was fairly stable thanks to the work of Jake Cleary and Sam Saccone.
2. Jake went onto other things and Jeet was left unmaintained.
3. Jeet got new maintainers who wanted to introduce some concepts people had been asking about (aliases and such).
4. 6.1.3 introduced breaking changes that were present in 6.1.3 and 6.1.4.
5. 6.1.5 rolled back to 6.1.2
6. 💥 7.0.0 cleans up lots of things, breaks lots of things, and will adhere to semver strictly from here on out.

Semver is hard because of the whole "marketing" thing. I sucked at it for years because I couldn't bring myself to do a major release for a small issue. This has caused users plenty of grief. If anyone deserves to have a finger pointed at them, it's me for not setting a higher standard for the versioning of this project early on.

7.0.0+ aims to simplify the codebases by removing things like aliases; syncing API param names between ports; making some variables more explicit (although there's lots of work to do there); and just generally put Jeet on a path where we can do major iterations quickly.

Don't be surprised if you wake up tomorrow and Jeet is on version 19.1.4 or something. This is the correct way to do semver if you didn't nail the API before 1.0.0, and we'll document changes in releases (old version changes are documented in 6.1.5's CHANGELOG.md (which you can checkout).

Migration Strategy

7.0.0 removes Bower completely

Bower is old and needs to end. Just consolidate all dependencies to package.json. If those packages don't exist for npm, they're very easy to publish (although almost any relevant Bower pkg has an npm counterpart).

7.0.0 removes superfluous directories and renames jeet.scss and jeet.styl to index.scss and index.styl.

Before 7.0.0 we had a directory structure like this:

./jeet
  - scss
    - jeet
      - index.scss

This was mostly so we could house port-related documentation in their respective folders, but that's a silly reason to have an extra directory, so 7.0.0 gets rid of it and now directory structure looks like this:

./jeet
  - scss
    - index.scss

If you are manually @importing Jeet, you will need to change the path to match this new structure.

• SCSS: If you were using a version (6.1.3, 6.1.4 -- I think) that converted index.scss to jeet.scss, migrate back index.scss. @import '.../jeet'; becomes @import '.../jeet/index';.
• Stylus and Node: It should work the same as before. Other import methods:

I don't care how Sass imports libs by name. library_name/library_name.scss is a stupid convention Sass is forcing on people. library_name/index is a convention throughout the rest of the programming world. Sass admits this in an issue that's been open for years, but they haven't, and probably won't, fix this.

$uncycle is completely removed and forever banished

I figured out a way to remove the need for $uncycle using nth trickery so it has been officially removed from the API. All you have to do is go through your code and remove all mentions of it and everything should JustWork™.

shift() and unshift() have been renamed to move() and unmove() to prevent potential clashes with Stylus built-in shift() function

Go through projects and rename shift() and unshift() to move() and unmove().

All aliasing has been removed and will remain removed

Jeet's simple/readable API is impossible to clash with W3C Specs since the preprocessor will process these mixins before they ever get to the browser.

The only thing Jeet's API could clash with is preprocessors introducing new functions (like above). Preprocessors have dramatically slowed down their development (with the advent of PostCSS) and will likely not introduce/modify their APIs.

If they do (they won't):

0. You shouldn't blindly do a major upgrade to any package, even a preprocessor. So ping us if there is a change and we'll update Jeet.
1. Just lock the major preprocessor version with the major Jeet version you're currently using and voila.

But I loooove aliases!!!

You can write custom aliases for anything. They're very easy. Just wrap mixins in an aliased mixin.

Examples:

// Namespace Example
@mixin jeet-column($args...) {
  @include column($args...);
}

// Alias Example
@mixin col($args...) {
  @include column($args...);
}

// Namespace Example
jeet-column()
  column(arguments)

// Alias Example
col()
  column(arguments)

So, if you are already using namespaces and aliases throughout a large project, preferably find+replace them with the new simple/explicit mixins. If you insist on custom namespaces/aliases, you can create them.

SCSS uses a map for its default settings now instead of individual variables

It's a bit more verbose, but this seems like the right way to approach this.

Just go through your mixins, and anywhere you're actually calling a global setting, replace it with map-get. For example: $gutter: map-get($jeet, 'gutter').

Refer to SCSS' API reference to see where all we're using maps now.

Feel free to simply replace the map with individual variables like before if you're not a fan of map-get.

cf() is now clearfix()

This is part of the whole alias-removal thing above. Feel free to manually re-alias it.

edit() is now debug()

More descriptive of what it's doing.

$g in size-getting functions (column-width(), column-gutter()) has been changed to the more explicit $gutter

Anywhere you're using those functions, just ensure if you are using the named argument of $g to upgrade it to $gutter.

---

I don't think there is anything else, but if you come across some weirdness while upgrading, open an issue or chat with us on Gitter and we'll help you through it and update this document.