Some dependencies that rely on window don't work #333

mix3d · 2017-12-18T17:39:38Z

BUG:
An older website that imports jQuery and Bootstrap from locally downloaded files don't have their dependencies properly running; Bootstrap complains that jQuery and $ are not found. It seems that either the order from the HTML is not respected, or that JS that installs to the root window are not working correctly.

🎛 Configuration (.babelrc, package.json, cli command)

        <script src="LIBS/jquery.min.js"></script>
        <script src="LIBS/bootstrap.min.js"></script>

$> parcel index.html

🤔 Expected Behavior

Imported scripts run correctly

😯 Current Behavior

Bootstrap complains about not finding jquery. Not sure if import order or window problem

🔦 Context

Can't use Parcel if this doesn't work for older / retrofit websites.

🌍 Your Environment

Software	Version(s)
Parcel	1.2.0
Node	v8.9.1
npm/Yarn	npm v5.5.1
Operating System	Windows 10

The text was updated successfully, but these errors were encountered:

benhutton · 2017-12-20T16:39:23Z

We're seeing a lot of this, too, trying to get some legacy code working with Parcel

brandon93s · 2017-12-22T04:48:41Z

This seems like a valid use case for a parcelignore. They're being included in the correct order, but I'm guessing the closure scope is preventing them from mounting to the window correctly.

benhutton · 2017-12-27T15:01:52Z

some of my problems here seem to go away by using jquery off of CDN instead of bundling in a node package. Probably more performant that way, anyways... Still investigating to see if that fixes everything.

mix3d · 2017-12-27T19:56:19Z

Sometimes corporate policy requires self hosting all dependencies

wywywywy · 2017-12-27T20:06:53Z

Hi.

I tried using a CDN, a local link, and node modules, nothing works.

This is a very simple HTML that I used to test.

<!DOCTYPE html>
<html lang="en">
<head>
	<title>Test</title>
	<meta charset="utf-8">
	<meta name="viewport" content="width=device-width, initial-scale=1">
	<!-- JQuery -->
	<script src="import/jquery-3.2.1.min.js"></script>
	<!-- Bootstrap JS and CSS -->
	<link rel="stylesheet" href="import/bootstrap/css/bootstrap.min.css">
	<script src="import/bootstrap/js/bootstrap.min.js"></script>
</head>
<body>
    <div id="test"></div>
</body>
<script>
    $('#test').text('aaa');
</script>
</html>

benhutton · 2018-01-02T14:26:31Z

@DeMoorJasper @brandon93s I'm not sure how .parcelignore would fix this. I don't want to ignore these files... I want parcel to manage everything and for it to work! If I include jquery separately from CDN, before my parcel bundle, it works. I would rather include it in my parcel bundle.

DeMoorJasper · 2018-01-02T14:46:32Z

@benhutton parcelignore could possibly just copy over the files without any processing making this exactly the same as using a cdn for example and hopefully mounting to the window correctly.
Although a better fix would be a more solid way to go, possibly removing the need for parcelignore (which is currently still RFC)

benhutton · 2018-01-02T14:52:58Z

@DeMoorJasper so I would still somehow be able to leverage jquery from npm?

wywywywy · 2018-01-02T14:54:22Z

Yes I would be pretty happy if it can just bundle our code without touching the 3rd party libraries.

DeMoorJasper · 2018-01-02T14:57:09Z

@benhutton is that not currently possible? If u approach jQuery as a node_module it should work just fine, because it never has the need to mount to the window?

something like

const $ = require('jQuery');

$("#somethin")....

DeMoorJasper · 2018-01-02T15:01:32Z

Also another way to fix this would be to detect how many packages are being bundled and just leave sole packages/libraries without imports alone.
All these things i'm proposing sound and kinda are hotfixes/short term solutions.

Like discussed in another issue the proper end-game for bundling would be to remove the need of the prelude entirely, so that code is just bundled in a smaller package and doesn't perform any unexpected behaviour.

benhutton · 2018-01-02T15:25:36Z

unfortunately, const $ = require('jQuery'); doesn't work for me. At least, I can't do that at the top level and have it work everywhere (like I could with webpack, which we're moving from). I think it works if I do that in every single file that uses jquery.

mix3d · 2018-01-02T19:08:10Z

@benhutton Since bootstrap (at least the self downloaded one) seems to require jQuery on the window scope, and fails if not found, I'm not sure how to solve that multi-dependency.

antony · 2018-01-08T15:56:23Z

Like @benhutton I have also been stymied by the fact that const $ = require('jquery') doesn't work, so right now I don't know a way past this.

terminalqo · 2018-01-15T09:18:37Z

same problem, how to use jquery with parcel? need help

devongovett · 2018-01-16T08:07:37Z

This is because jQuery disables setting itself on the window global in a CommonJS environment (which Parcel is). See https://github.com/jquery/jquery/blob/master/src/wrapper.js#L29 and https://github.com/jquery/jquery/blob/2d4f53416e5f74fa98e0c1d66b6f3c285a12f0ce/src/exports/global.js#L30-L32.

If you need it to be accessible on window, you could do something like window.$ = require('jquery'). Does that work?

windware-ono · 2018-01-22T05:37:26Z

I'm using TypeScript but this did expose '$' to 'window' for jquery-ui etc to consume it.

import * as $ from 'jquery'
(<any>window).$ = (<any>window).jQuery = $

I have a question, but how can I access any of the classes being declared in the bundled JS without individually exporting them like above?

I found that they're listed in 'window.require.cache[N].exports.default' where N is some number I haven't specified but is there a way to access those by class names?

How am I supposed to access class methods in the bundled JS from within inline HTML such as through 'onclick' properties?

Currently I'm exporting every classes that need exposed the same way as jQuery above which is bit of a work since I can't iterate over a directory in the entry point script but have to manually list them all (which needs updating from time to time).

laosb · 2018-10-19T08:42:51Z

Hitting this when using EaselJS 1.x versions.

import 'easeljs/lib/easeljs.min.js'

complains createjs wasn't there.

devongovett · 2018-11-04T23:01:39Z

I'm not sure what we should do about this. The cause of this issue is that jQuery relies on this being the global object, but in a CommonJS environment (which Parcel emulates) this refers to the module object.

Perhaps we could make it so that if you imported a script from HTML, it would retain this in the entry module, but as soon as you require it would turn into the module object since it is in a common js context. Then you could have <script type="commonjs"> and <script type="module"> for commonjs and ES6 module environments. Obviously this is a breaking change from the current default, but with Parcel 2 on the horizon I'd like to revisit this issue and get some options that make sense. Thoughts?

trickydisco78 · 2019-02-21T11:01:54Z

I solved this by adding this code

  _jQuery = window.jQuery,
  // Map over the $ in case of overwrite
  _$ = window.$;

jQuery.noConflict = function(deep) {
  if (window.$ === jQuery) {
    window.$ = _$;
  }

  if (deep && window.jQuery === jQuery) {
    window.jQuery = _jQuery;
  }

  return jQuery;
};

// Expose jQuery and $ identifiers, even in AMD
// (#7102#comment:10, https://github.com/jquery/jquery/pull/557)
// and CommonJS for browser emulators (#13566)
if (!noGlobal) {
  window.jQuery = window.$ = jQuery;
}```

in the top of the file (linked to above)

parcel-bundler/parcel#333

sundayz · 2019-06-21T19:50:27Z

2 and a half years and nobody posted at least a workaround?

This worked for me in a project that uses bootstrap and jquery. In my app.js (entry point for parcel):

import jQuery from "jquery";
window.$ = window.jQuery = jQuery; // workaround for https://github.com/parcel-bundler/parcel/issues/333
import 'bootstrap/dist/js/bootstrap.bundle';

Import order matters. Couldn't get it to work with the normal bootstrap js include because it couldn't resolve the dependency for Popper, even though I'm not using tooltips or popper anywhere.

taducquang · 2019-07-17T22:00:44Z

So only workaround? I think gulp doesn't have this issue.

antony · 2019-07-18T09:38:03Z

@taducquang gulp isn't a bundler.

The vendored jquery version was 1.9.1 from 2013-02-04. Let's replace it with the most recent one from the 1.x branch (1.12.4 from 2016-05-20). The modification in rjquery.js is needed because recent jQuery versions changed their behaviour, and do not set themselves on the global window object. See: parcel-bundler/parcel#333 (comment) This will be the lastest jQuery 1.x version ever, because 1.x branch is definitively EOLed (see jquery/jquery.com#162). This is a stopgap measure to get the latest security fixes. Going forward, another strategy will be needed. Closes #3640

stoically · 2019-11-04T09:23:44Z

The workaround from @sundayz

import jQuery from "jquery";
window.$ = window.jQuery = jQuery;
import "lib-that-depends-on-jQuery";

didn't work for me, since the library that depends on jQuery does so in a sync way, and because parcel ends up generating

"use strict";
var _ = _interopRequireDefault(require("jquery"));
require("lib-that-depends-on-jQuery");
function _interopRequireDefault(obj) { return obj && obj.__esModule ? obj : { default: obj }; }
window.$ = window.jQuery = _.default;

assigning jQuery on window happens too late.

Combining the workaround with the hint from @devongovett does the trick for me:

const jQuery = require("jquery")
window.$ = window.jQuery = jQuery;
require("lib-that-depends-on-jQuery")

since parcel generates in that case

var jQuery = require("jquery");
window.$ = window.jQuery = jQuery;
require("lib-that-depends-on-jQuery");

flip111 · 2020-03-27T23:27:48Z

var jQuery = require("jquery");
window.$ = window.jQuery = jQuery;
require("lib-that-depends-on-jQuery");

This works for me if lib-that-depends-on-jQuery only uses an instance of jQuery. I tested it with select2 and this condition to test for jQuery absence does not trigger.

However ..

select2 extends jQuery functionality, but the "upgraded" jQuery instance is not available.

That is: the jQuery instance is not mutated (to be upgraded)
And also: the return value from const foo = require('select2/dist/js/select2.js'); is not a jQuery instance but instead something with signature of function exports(root, jQuery).

Does someone have this working with a library that extends jQuery ??

flip111 · 2020-03-27T23:53:27Z

My suspicion is that another library can make use of jQuery through 3 methods:

grab it from window (i guess this would be useful when jQuery was loaded in CommonJS but dependent libraries are outside of CommonJS)
the library can try to require jQuery itself through require('jquery'), however this can sometimes fail depending on how your paths are loaded (you can try require('jquery') in your own code to see if it works.
the library can accept an instance of jQuery (and fallback to trying to load it itself), this is my preferred method because you have full control where jQuery and other library get loaded from and you also have control of the jQuery instances (for plugins)

As example of 3

const jQuery_tmp = require('cash-dom/dist/cash.min.js'); // using jQuery compatible library
const $ = require('select2/dist/js/select2.js')(jQuery_tmp); // Let the plugin do it's thing

mix3d · 2020-04-02T23:12:39Z

@flip111 That's all fine and good if you are the library owner. If you are just importing something like Bootstrap, however, you as a dev don't really have control over how a dependency like jQuery is looked for.

flip111 · 2020-04-03T10:39:41Z

My suspicion is that another library can make use of jQuery

@mix3d you shouldn't take this too literally. Replace "another library" by "your app".

You see here that if you include bootstrap, including jQuery is a separate step that is not within the code of bootstrap itself. This is the same if you are using import statements.

If you have code that is going "to look for jQuery", you should select the method of making jQuery available in such a way that it corresponds to the ways the code is looking for jQuery.

fawazahmed0 · 2020-11-30T20:15:49Z

This worked for me:
import $ from 'jquery'

DeMoorJasper added 🐛 Bug ✔️ Confirmed Bug labels Dec 18, 2017

DeMoorJasper mentioned this issue Dec 31, 2017

[WIP/RFC] .parcelignore #448

Closed

3 tasks

DeMoorJasper mentioned this issue Jan 9, 2018

Use of libs with old dependencies (jQuery, jQuery-ui, angular 1.5.x, etc) #519

Closed

DeMoorJasper mentioned this issue Jan 19, 2018

use jquery demo and $ is not defined #585

Closed

brandon93s mentioned this issue Feb 14, 2018

🐛 Can't resolve dependence #260

Closed

kptdobe mentioned this issue Sep 24, 2018

Using Parcel creates the mess in client side code adobe/helix-cli#211

Closed

devongovett added the static label Jan 6, 2019

This was referenced Jan 7, 2019

Including files from node_modules in index.html causes export issues. #1483

Closed

Loading libraries via script src doesn't create the global #2422

Closed

AlejandroAkbal added a commit to AlejandroAkbal/akbal.dev that referenced this issue May 3, 2019

Parcel tiene un error, me muevo a webpack

51f56e3

parcel-bundler/parcel#333

muxator mentioned this issue Sep 16, 2019

The included jquery version is vulnerable ether/etherpad-lite#3640

Closed

LukeTOBrien mentioned this issue Jan 25, 2020

Import jQueryUI widget #4037

Closed

mischnic mentioned this issue Dec 3, 2020

Distinguish between module and classic scripts #5398

Closed

devongovett mentioned this issue May 30, 2021

Implement support for classic scripts and automatic module/nomodule #6247

Merged

devongovett closed this as completed in #6247 Jun 19, 2021

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Some dependencies that rely on window don't work #333

Some dependencies that rely on window don't work #333

mix3d commented Dec 18, 2017

benhutton commented Dec 20, 2017

brandon93s commented Dec 22, 2017

benhutton commented Dec 27, 2017

mix3d commented Dec 27, 2017 via email •

edited

Loading

wywywywy commented Dec 27, 2017 •

edited

Loading

benhutton commented Jan 2, 2018

DeMoorJasper commented Jan 2, 2018 •

edited

Loading

benhutton commented Jan 2, 2018

wywywywy commented Jan 2, 2018

DeMoorJasper commented Jan 2, 2018 •

edited

Loading

DeMoorJasper commented Jan 2, 2018 •

edited

Loading

benhutton commented Jan 2, 2018

mix3d commented Jan 2, 2018

antony commented Jan 8, 2018

terminalqo commented Jan 15, 2018

devongovett commented Jan 16, 2018

windware-ono commented Jan 22, 2018 •

edited

Loading

laosb commented Oct 19, 2018

devongovett commented Nov 4, 2018 •

edited

Loading

trickydisco78 commented Feb 21, 2019 •

edited

Loading

sundayz commented Jun 21, 2019

taducquang commented Jul 17, 2019

antony commented Jul 18, 2019

stoically commented Nov 4, 2019 •

edited

Loading

flip111 commented Mar 27, 2020

flip111 commented Mar 27, 2020

mix3d commented Apr 2, 2020 •

edited

Loading

flip111 commented Apr 3, 2020

fawazahmed0 commented Nov 30, 2020

Some dependencies that rely on window don't work #333

Some dependencies that rely on window don't work #333

Comments

mix3d commented Dec 18, 2017

🎛 Configuration (.babelrc, package.json, cli command)

🤔 Expected Behavior

😯 Current Behavior

🔦 Context

🌍 Your Environment

benhutton commented Dec 20, 2017

brandon93s commented Dec 22, 2017

benhutton commented Dec 27, 2017

mix3d commented Dec 27, 2017 via email • edited Loading

wywywywy commented Dec 27, 2017 • edited Loading

benhutton commented Jan 2, 2018

DeMoorJasper commented Jan 2, 2018 • edited Loading

benhutton commented Jan 2, 2018

wywywywy commented Jan 2, 2018

DeMoorJasper commented Jan 2, 2018 • edited Loading

DeMoorJasper commented Jan 2, 2018 • edited Loading

benhutton commented Jan 2, 2018

mix3d commented Jan 2, 2018

antony commented Jan 8, 2018

terminalqo commented Jan 15, 2018

devongovett commented Jan 16, 2018

windware-ono commented Jan 22, 2018 • edited Loading

laosb commented Oct 19, 2018

devongovett commented Nov 4, 2018 • edited Loading

trickydisco78 commented Feb 21, 2019 • edited Loading

sundayz commented Jun 21, 2019

taducquang commented Jul 17, 2019

antony commented Jul 18, 2019

stoically commented Nov 4, 2019 • edited Loading

flip111 commented Mar 27, 2020

flip111 commented Mar 27, 2020

mix3d commented Apr 2, 2020 • edited Loading

flip111 commented Apr 3, 2020

fawazahmed0 commented Nov 30, 2020

mix3d commented Dec 27, 2017 via email •

edited

Loading

wywywywy commented Dec 27, 2017 •

edited

Loading

DeMoorJasper commented Jan 2, 2018 •

edited

Loading

DeMoorJasper commented Jan 2, 2018 •

edited

Loading

DeMoorJasper commented Jan 2, 2018 •

edited

Loading

windware-ono commented Jan 22, 2018 •

edited

Loading

devongovett commented Nov 4, 2018 •

edited

Loading

trickydisco78 commented Feb 21, 2019 •

edited

Loading

stoically commented Nov 4, 2019 •

edited

Loading

mix3d commented Apr 2, 2020 •

edited

Loading