GithubHelp home page GithubHelp logo

dojo / util Goto Github PK

View Code? Open in Web Editor NEW
60.0 31.0 105.0 151.11 MB

Dojo 1 - build utilities. Please submit bugs to https://bugs.dojotoolkit.org/

Home Page: https://dojotoolkit.org/

License: Other

JavaScript 46.85% Shell 1.73% XSLT 4.91% CSS 0.33% Java 11.13% Ruby 0.08% PHP 24.47% Batchfile 0.12% HTML 10.10% Hack 0.03% sed 0.25%

util's Introduction

util

util is a set of utilities developed to utilise with the Dojo Toolkit. It is best to read the documentation to understand what tools are available within the repository.

While still being maintained, new development is primarily focused on modern Dojo.

Checkout the Dojo framework website or if you want a more detailed technical status and overview, checkout the Dojo roadmap.

Installing

Installation instructions are available at dojotoolkit.org/download.

Getting Started

If you are starting out with Dojo, the following resources are available to you:

License and Copyright

The Dojo Toolkit (including this package) is dual licensed under BSD 3-Clause and AFL. For more information on the license please see the License Information. The Dojo Toolkit is Copyright (c) 2005-2018, The JS Foundation. All rights reserved.

util's People

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

util's Issues

Bower install fails

When installing dojo/util via bower, I receive the error "Package dijit-themes not found". See below

$ bower install --save dojo/util
bower util#*                    cached https://github.com/dojo/util.git#1.16.3
bower util#*                  validate 1.16.3 against https://github.com/dojo/util.git#*
bower dojox#1.16.3              cached https://github.com/dojo/dojox.git#1.16.3
bower dojox#1.16.3            validate 1.16.3 against https://github.com/dojo/dojox.git#1.16.3
bower dijit-themes#1.15.0-pre        ENOTFOUND Package dijit-themes not found

Update CLDR

The CLDR shipped with dojo 1.16.3 is the version 30, if I'm correct.
The last version should be shipped.
Tried to build from CLDR 38 (following https://dojotoolkit.org/reference-guide/1.10/dojo/cldr.html) but there are some errors during the build process.

Ie:

Syntax error in C:\Users\username\Downloads\dojo-release-1.16.3-src\dojo\cldr\nls\de\number.js// generated from ldml/main/*.xml, xpath: ldml/numbers

and, the number.js for de is malformed:

....
	'currencyFormat-short':"0 Mrd'.' ¤",
	'currencyFormat-short':"0 Mrd'.' ¤",
	'currencyFormat-short':"00 Mrd'.' ¤",
	'currencyFormat-short':"00 Mrd'.' ¤",
	'currencyFormat-short':"000 Mrd'.' ¤",
	'currencyFormat-short':"000 Mrd'.' ¤",
	'currencyFormat-short':"0 Bio'.' ¤",
	'currencyFormat-short':"0 Bio'.' ¤",
	'currencyFormat-short':"00 Bio'.' ¤",
	'currencyFormat-short':"00 Bio'.' ¤",
	'currencyFormat-short':"000 Bio'.' ¤",
	'currencyFormat-short':"000 Bio'.' ¤"{0} Tag{0} Tage{0}. Abzweigung nach rechts nehmen… für {0} …… mit {0} …Anstatt {0} …{0} kostet (kosten) € 3,50.Die {0} ist …Der {0} ist …Das {0} ist …
})

building dojo project no longer generates output files after update to 1.17

In our product, we use the dojo build to deploy a number of layers, which are optimized using the closure compiler.
After updating to 1.17 we find that, while it does produce the .consoleStripped.js and .uncompressed.js output files, the actually optimized files are no longer generated.

Please note that we already (locally) upgraded the closureCompiler to version 20210601 to allow us to use the newer style JavaScript syntax. Just swapping the 1.17.3 version with this older version fixes the problem of the generated output files.

1.16.3 by default generates at least ECMAScript 2015, while it was ECMASCRIPT3 in 1.16.2 and earlier

In 1.16.2 -> 1.16.3, the closure compiler was updated.

1.16.2

jand@Desjani:pictoperfect-buildenv>java -jar src/uiBuild/yymmdd-HHMM/lib/util/closureCompiler/compiler.jar --version
Closure Compiler (http://github.com/google/closure-compiler)
Version: v20160911
Built on: 2016-09-13 16:51

1.16.3

jand@Desjani:pictoperfect-buildenv>java -jar src/uiBuild/yymmdd-HHMM/lib/util/closureCompiler/compiler.jar --version
Closure Compiler (http://github.com/google/closure-compiler)
Version: v20200112
Built on: 2020-01-13 22:21

That's quite a jump, of over 3 years.

A new build, created with util [email protected], fails on legacy infrastructure.

The reason is that the closure compiler outputs a more modern version of JavaScript. As an example, 1.16.3 outputs shorthand property names:

c.definitions = {
          Math,
          window,
          global: window,
          module: k.selfResolving(function(a, b) {
  …

where 1.16.2 does not:

root.definitions = {
…
		Math: Math,
		window: window,
		global: window,
		module: expression.selfResolving(function(mid, lazy){

As far as I know, shorthand property names are an ECMAScript 2015 feature.

From the closure compiler release notes, I learn that a command line property --language_out was added in release

The release notes for v20170806 say

August 6, 2017 (v20170806)


ECMASCRIPT_2017 is now the default language mode.

The output language defaults to ES5 instead of to the input language.

The release notes for v20170806 say

August 5, 2018 (v20180805)

You can now specify STABLE for input and/or output language level to request the latest version of JavaScript that is fully supported by the compiler. Currently, this means ES_2017 for input and ES5 for output.

I can find no other references to changes in the output language level in the release notes, so I need to assume that it is
still (intended to be) ES5. So either this is wrong, or the dojo build system is actively requesting another output language level. I cannot find prove of this. Yet, experiments show that the new setup by default generates at least ECMASCRIPT_2015.

Workaround

The more recent closure compiler supports a --language_out command line property;

v20200112 --help says:

 --language_out VAL                     : Sets the language spec to which
                                          output should conform. Options:
                                          ECMASCRIPT3, ECMASCRIPT5, ECMASCRIPT5_
                                          STRICT, ECMASCRIPT_2015, ECMASCRIPT_20
                                          16, ECMASCRIPT_2017, ECMASCRIPT_2018,
                                          ECMASCRIPT_2019, STABLE

After much searching, I found out that we can add a optimizeOptions property to our build profile build.profile.js:

…
  mini: true,
  optimize: "closure",
  layerOptimize: "closure",
  optimizeOptions: {
    languageOut: "ECMASCRIPT3"
  },
  stripConsole: "normal",
…

that generates a working build.

languageOut: "ECMASCRIPT5" generated a build that does not work, so it seems that 1.16.2 -> 1.16.3 does a jump from ECMASCRIPT3 to ECMASCRIPT_2015 or later.

The use of optimizeOptions in the build profile is not documented. But, in our build process at least, it is copied into bc, which is included from util/build/buildControl.js, which is used in util/build/transforms/optimizer/sendJob.js which calls util/build/optimizeRunner.js, where it is used as command line argument in the runJava call.

Suggestion

This is quite a jump for a patch version 1.16.2 -> 1.16.3.

I suggest

  • releasing a 1.16.4 where
    • the --languageOut parameter passed to the closure compiler defaults to "ECMASCRIPT3" (by adding it in util/build/buildControlBase.js, which would then be used both by util/build/transforms/optimizer/sendJob.js and util/build/transforms/optimizer/closure.js); alternatively, we can try to use the closure compiler option --browser_featureset_year
    • the use of optimizeOptions.languageOut in the build profile is documented
  • removing the default --languageOut parameter passed to the closure compiler not earlier than 1.17

Closure Compiler Error with ES6 code and Dojo 1.16.0?

https://discourse.dojo.io/t/closure-compiler-strict-errors/456

As reported by yassam:

I’m using Dojo 1.16.0.

The Dojo build system is giving me INTERNAL COMPILER ERROR on my ES6 code. I figure this might be due to a buggy version of the Closure compiler shipped with Dojo, so I downloaded the latest version of the Closure compiler and I now get a bunch of errors in the dojo code itself.

It complains about dojo code not compiling in strict mode, even though I haven’t set strict mode.

Specifically, here’s the relevant part of my build profile:

layerOptimize: 'closure',
optimize: 'closure',

optimizeOptions: {
languageIn: 'ECMASCRIPT6',
languageOut: 'ECMASCRIPT5'
},

Note that the input language is ECMASCRIPT6 not ECMASCRIPT6_STRICT

Is there an easy way to get the latest version of the closure compiler to work?

Build throws syntax errors for ES6+ code even when transforming back to ES3

Look like this is a recurring issue but I wanted to open this anyways.

for reference:
Stack Overflow Question
Dojo Bug Ticket

It is my understanding that by adding optimizeOptions with languageIn/languageOut (which are also defaulted) the Closure Compiler will transform the ES6+ code to an earlier version of ECMAScript.

When we do this, it looks like in the process of the build, there is a util/build/transform/depsScan to see if the module and its deps are "Pure AMD" BEFORE the transformation of langIn -> langOut happens.

Is it absolutely necessary to keep the order of the gates as is, or can we reorder them so that the transformation to ES5- happens first and then the AST depsScan happens next?

Is there a status on how to solve this issue? Or should I just live with all the console errors and ignore them since what is a syntax error is being transformed anyways?

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.