Materialize: Move some JS dependencies to peerDependencies

[patrys]

Currently jQuery is listed as a package.json dependency that causes npm and webpack to give Materialize its own private copy of jQuery (living in its node_modules subdirectory). The result is that there are two separate jQuery versions in your project and Materialize's jQuery plugins become unreachable.

Moving jquery to peerDependencies would solve the problem and would make Materialize share the single jQuery installation with the rest of the project it's used in.

Hammer is listed as a package.json dependency but it's also bundled in compiled files in both dist and bin. For projects that wish to use Materialize as an npm package this is quite wasteful and leads to code duplication.

Moving hammerjs to peerDependencies and either removing it from the compiled copy in dist or (preferably) providing a commonjs entry point to the original code in js directory would solve this.

[arlowhite]

Also, there's:

• js/jquery.easing.1.3.js
• js/velocity.min.js

[arlowhite]

Somewhat related...I'm working on a angular-cli (webpack) project. The code in initial.js was not finding jQuery.

For some reason, the global jQuery is undefined, but window.jQuery exists. Maybe this is due to zone.js?

So initial.js should be changed to:

// Check for jQuery.
if (typeof(jQuery) === 'undefined') {

  var jQuery;
  // Projects with zone.js will only have jQuery in the window object
  if (typeof(window.jQuery) !== 'undefined') {
    jQuery = $ = window.jQuery;
  }
  // Check if require is a defined function.
  else if (typeof(require) === 'function') {
    jQuery = $ = require('jquery');
  // Else use the dollar sign alias.
  } else {
    jQuery = $;
  }
}

[smeijer]

The hard and bundled dependencies in this project are starting to be a reason for me to switch over to another css framework.

I had to debug an issue last week where materialize was not bound to jQuery. Turned out to be a version problem. I had upgraded to a more recent version, where as materialize was using it's own bundled version of jQuery.

Some while ago I had a lot of difficulties with Velocity (#4212) , and also the easing part has thrown me some issues.

Please take this issue seriously. Although the bundle size does matter; it's not "just the bundle size". The issue lies in double dependencies and possible conflicts.

[smeijer]

Also; please add pickadate / picker.js to the list.

[tomscholz]

@patrys PeerDependencies are deprecated since npm 3. If anyone has any suggestions please post them.
Materialize comes bundled with:

jquery.easing
velocity-animate
hammerjs
jquery.hammer.js

pickadate
waves

@smeijer we use a modified version of amsul/pickadate.js, so we can't add it directly as a dependency.

EDIT:
We also do use fians/Waves for the wave effect. I am not sure if we made a lot of modifications to it. cc @acburst @Dogfalo

[fega]

@tomscholz @patrys what about a bundled and an unbundled version?

[albe]

How about this:

Add the external dependencies normally in package.json. Create two build versions: full which bundles all dist files from respective node_modules and is b/c and base which only contains the base code without external deps.
Then add adapters that do code checks for availability of the dependencies inside global namespace to activate the specific functionalities or error out for missing required dependencies (if any).

It will be easier to update dependencies (for example Waves is still at 0.6.4), it will allow people to opt into only including plugins/features they want by loading them themself and hence prevent version mismatch/double inclusion issues.

PS: Changes to Waves seem minimal looking at https://github.com/Dogfalo/materialize/commits/master/js/waves.js

[Dogfalo]

The only unmodified libraries we include are Velocity and Hammer. We plan to remove Hammer in the future.

[fega]

@Dogfalo @tomscholz I think that the modified libraries should be refactored to interfaces...

It will solve the problems with duplicate dependencies and will make easier to update the third party libraries without all the pain.

[Dogfalo]

What do you mean by that?

On Wed, Jul 12, 2017 at 11:00 AM, Fabian Gutierrez <[email protected]

wrote:

@Dogfalo https://github.com/dogfalo @tomscholz
https://github.com/tomscholz I think that the modified libraries should
be refactored to some interfaces...

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/Dogfalo/materialize/issues/3707#issuecomment-314848879,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACpaxwrOa_VwNQc_PnPkq4FiMIRu7npDks5sNQnNgaJpZM4KLGwZ
.

--
Doggy sends his greetings from Mars.

[fega]

@Dogfalo I don't know if there is a better word for that but...

you know that when you travel to another country and you want to use your laptop sometimes you need an adapter to charge it, right?

So imagine that your laptop is a dependency, the adapter is an interface and the wall is materialize

if you want to buy a new laptop, you can connect it to the same adapter or change it for a different one, but is a little and cheap adapter

[fega]

@Dogfalo it makes sense?

also @tomscholz the peerDependencies are not deprecated, the only deprecation was a change of the behavior of the package manager, that doesn't install the packages in peerDependencies automatically.

[Dogfalo]

We've removed many of the dependencies, so this is less of an issue now. We don't wan't to create a bundled and unbundled version as that comes with its own complexity especially for beginner developers. The last dependency will be removed when Web Animations API is in a more complete state.