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

Forked domtokenlist #147

Closed
jantimon opened this issue Aug 22, 2016 · 11 comments
Closed

Forked domtokenlist #147

jantimon opened this issue Aug 22, 2016 · 11 comments
Labels

Comments

@jantimon
Copy link
Contributor

I don't understand why the domtokenlist is a fork.
Do you really need the UMD handling?

https://github.com/jwilsson/domtokenlist/compare/master...rodneyrehm:4ccd85f5662e674bd9a7d1a9e121eb49de42a14a?expand=1

We got some firewall issues which do not allow to install directly from github.
Do you think we can get your fork merged and use npm again?

@rodneyrehm
Copy link
Member

Do you really need the UMD handling?

yes. The tests (using intern) require AMD. The build (using browserify) requires CommonJS. Until there is a decent support for ES6 modules in a test framework like Intern, I fear I'm stuck with this module mess.

We got some firewall issues which do not allow to install directly from github.

interesting.

Do you think we can get your fork merged and use npm again?

My code already landed in the original project, but was reverted before they released 1.2.0. Because of that I kept the fork alive.

As I was generally unhappy with domtokenlist-shim, I went ahead and implemented my own tokenlist. However, I did not want to just swap the implementations, without making use of the additional functionality my own implementation.

The domtokenlist-shim is currently only loaded in focus-source.js and focus-within. We currently only need .classList.add() and .classList.remove().

It is entirely possible to drop the polyfill altogether and use one of the older approaches to this (i.e. do the string manipulation ourselves). I believe this would be the best course of action for now.


Are you using the bundle or individual modules? Maybe it would make sense to publish the bundle separately without dependencies, as they're already included anyway. That doesn't help if you're using individual modules, though…

@jantimon
Copy link
Contributor Author

jantimon commented Aug 22, 2016

Okay that's understandable.

Right now we are not using the bundle.
The current solution is a small helper ts file which picks directly the focus source file out of ally.js:

/**
 * Allow to distinguish between tab and mouse focus interactions
 * @see http://allyjs.io/api/style/focus-source.html
 *
 * Usage:
 * ```css
 * [data-focus-source='key'] :focus {
 *   background: orange;
 * }
 * ```
 */
const focusSource = <() => any> require('ally.js/style/focus-source.js');
module.exports = focusSource();

@rodneyrehm
Copy link
Member

The current solution is a small helper ts file which picks directly the focus source file out of ally.js

Does that mean you were able to work around the problem?

@jantimon
Copy link
Contributor Author

Only during development as npm install fails on the production machine

@jantimon
Copy link
Contributor Author

If you like I can prepare a pull request which uses string methods to add/remove the classes

@jantimon
Copy link
Contributor Author

#148 is now ready for review

@rodneyrehm
Copy link
Member

Merged! Thanks for your efforts! :)

I imagine you'd like a new release asap. As I'm still not in a position to release the other changes in master, I'll have to create another release based off v1.1.1 only containing this fix. Since we're removing a dependency that had a global effect (DOM prototype), I'm not sure if this should become 1.2.0 rather than 1.1.2…


You mentioned somewhere that you weren't able to run the tests locally. What was the problem?

@jantimon
Copy link
Contributor Author

Yes sure it would be cool to release 1.2.0 soon.
It's either a feature release 1.2.0 (works without domtoken plugin) or a breaking change release 2.0.0. (doesn't include domtoken plugin)

Local tests:
fish___users_jnicklas_desktop_ally_js_ _-fish_ _ 1

@rodneyrehm
Copy link
Member

Your contribution is now known as release 1.2.0 - Adios DOMTokenList - thank you for your efforts! :)

@rodneyrehm
Copy link
Member

regarding your ability to run tests…

  • Have you run npm run init or npm run clean && npm run build before running npm run test?
  • Are you by any chance using npm v3?

@jantimon
Copy link
Contributor Author

Thanks for the release 🎉🎉🎉

Moved the local testing problems into a new issue: #149
However although it is very slow it is also fine to work on a feature branch and let travis run the tests.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants