Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.javascript > #38611 > unrolled thread

3rd party scripts

Back to article view | Back to comp.lang.javascript

Contents

  3rd party scripts Andrew Poulos <ap_prog@hotmail.com> - 2020-07-28 07:59 +1000
    Re: 3rd party scripts "Evertjan." <exxjxw.hannivoort@inter.nl.net> - 2020-07-28 01:14 +0200
    Re: 3rd party scripts "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-07-27 18:19 -0700
      Re: 3rd party scripts "Michael Haufe (TNO)" <tno@thenewobjective.com> - 2020-07-27 18:21 -0700
    Re: 3rd party scripts Arno Welzel <usenet@arnowelzel.de> - 2020-07-28 04:38 +0200
    Re: 3rd party scripts Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2020-07-28 18:25 +0200
      Re: 3rd party scripts Thomas 'PointedEars' Lahn <PointedEars@web.de> - 2020-08-05 10:43 +0200

#38611 — 3rd party scripts

I have a website that uses 3rd party code (anime.js, driver.js...) The 
site works as expected but I have to manually check the 3rd party 
sources to see if there are any updates.

Then if there is an update I have to check what it is, download it, and 
then test the website with it.

Is this the nature of using 3rd party code or is there some "automated" 
way to handle it?

Andrew Poulos

[toc] | [next] | [standalone]

#38612

Andrew Poulos <ap_prog@hotmail.com> wrote on 27 Jul 2020 in 
comp.lang.javascript:

> I have a website that uses 3rd party code (anime.js, driver.js...) The 
> site works as expected but I have to manually check the 3rd party 
> sources to see if there are any updates.
> 
> Then if there is an update I have to check what it is, download it, and 
> then test the website with it.
> 
> Is this the nature of using 3rd party code or is there some "automated" 
> way to handle it?

You can check that and update that by serverside code, 
if you know how to detect the update, perhaps by comparing a verion number.

Unless you do that with serverside javascript, I would think that is off 
topic here. That the content is javascript is not the point.

Even if you do this automatically, I woud think you will have to check, if 
your web-page still works as intended, which you cannot do automatically.

-- 
Evertjan.
The Netherlands.
(Please change the x'es to dots in my emailaddress)

[toc] | [prev] | [next] | [standalone]

#38613

On Monday, July 27, 2020 at 4:59:26 PM UTC-5, Andrew Poulos wrote:
> I have a website that uses 3rd party code (anime.js, driver.js...) The 
> site works as expected but I have to manually check the 3rd party 
> sources to see if there are any updates.
> 
> Then if there is an update I have to check what it is, download it, and 
> then test the website with it.
> 
> Is this the nature of using 3rd party code or is there some "automated" 
> way to handle it?


There's a quick solution but it's also fragile and could inadvertently break things if the 3rd party script updates in an incompatible way:

Every script published to npmjs is also available on unpkg.com. For example, driver.js is published at:

<https://www.npmjs.com/package/driver.js>

The corresponding unpkg.com reference for use with a script tag would be:

<https://unpkg.com/driver.js>

which redirects to the latest version:

<https://unpkg.com/driver.js@0.9.8/dist/driver.min.js>

So I think this would solve your immediate problem but wouldn't suggest it.

The current popular solution is to define your website as a JavaScript project with a package.json defined and such and reference your dependencies that way. If your project is hosted on github you will even get a warning now of out of date dependencies and security issues. (Even with a pull request). 

For example, a library I'm building but haven't published yet was flagged as having a vulnerable dependency. I received an email and the repository had a warning displayed:

"""
We found a potential security vulnerability in one of your dependencies.
"""

A pull request was automatically created with a patch:

<https://github.com/final-hill/derivative-parser/pull/14>


So while the latter approach provides a better means of managing your project it is a far more difficult thing to set up after you already have a project/website deployed in a more traditional manner.

[toc] | [prev] | [next] | [standalone]

#38614

On Monday, July 27, 2020 at 8:19:07 PM UTC-5, Michael Haufe (TNO) wrote:
> On Monday, July 27, 2020 at 4:59:26 PM UTC-5, Andrew Poulos wrote:
> > I have a website that uses 3rd party code (anime.js, driver.js...) The 
> > site works as expected but I have to manually check the 3rd party 
> > sources to see if there are any updates.
> > 
> > Then if there is an update I have to check what it is, download it, and 
> > then test the website with it.
> > 
> > Is this the nature of using 3rd party code or is there some "automated" 
> > way to handle it?
> 
> 
> There's a quick solution but it's also fragile and could inadvertently break things if the 3rd party script updates in an incompatible way:
> 
> Every script published to npmjs is also available on unpkg.com. For example, driver.js is published at:
> 
> <https://www.npmjs.com/package/driver.js>
> 
> The corresponding unpkg.com reference for use with a script tag would be:
> 
> <https://unpkg.com/driver.js>
> 
> which redirects to the latest version:
> 
> <https://unpkg.com/driver.js@0.9.8/dist/driver.min.js>
> 
> So I think this would solve your immediate problem but wouldn't suggest it.
> 
> The current popular solution is to define your website as a JavaScript project with a package.json defined and such and reference your dependencies that way. If your project is hosted on github you will even get a warning now of out of date dependencies and security issues. (Even with a pull request). 
> 
> For example, a library I'm building but haven't published yet was flagged as having a vulnerable dependency. I received an email and the repository had a warning displayed:
> 
> """
> We found a potential security vulnerability in one of your dependencies.
> """
> 
> A pull request was automatically created with a patch:
> 
> <https://github.com/final-hill/derivative-parser/pull/14>
> 
> 
> So while the latter approach provides a better means of managing your project it is a far more difficult thing to set up after you already have a project/website deployed in a more traditional manner.

Also you can't avoid testing, but you can at least automate a significant amount of it depending on how much effort you spend getting your project into a testable form. Testing can be a simple as trying out some use cases or as complicated as comparing your website to some mockups:

<https://www.npmjs.com/package/screenshots-diff>

[toc] | [prev] | [next] | [standalone]

#38615

Andrew Poulos:

> I have a website that uses 3rd party code (anime.js, driver.js...) The 
> site works as expected but I have to manually check the 3rd party 
> sources to see if there are any updates.
> 
> Then if there is an update I have to check what it is, download it, and 
> then test the website with it.
> 
> Is this the nature of using 3rd party code or is there some "automated" 
> way to handle it?

Well - downloading could be automated on the server. But *testing* is
still needed, since you don't know, if your website still works with a
newer version of a third party script.

In fact you would need a kind of build environment where you can run a
development copy of your site for this. Testing could be automated with
Cypress where you define actions and the expected result.


-- 
Arno Welzel
https://arnowelzel.de

[toc] | [prev] | [next] | [standalone]

#38617

Andrew Poulos wrote:

> I have a website that uses 3rd party code (anime.js, driver.js...) The
> site works as expected but I have to manually check the 3rd party
> sources to see if there are any updates.
> 
> Then if there is an update I have to check what it is, download it, and
> then test the website with it.
> 
> Is this the nature of using 3rd party code or is there some "automated"
> way to handle it?

The way this works now *protects* you because your code may become 
incompatible to the third-party code if it is updated.

In theory, there is semantic versioning, with which developers can make 
updates to their code and indicate that the new version only fixes bugs or 
introduces new features, but does not break any existing code:

- A change from version 1.4.21 to 1.4.22 would indicate that only bugs were
  fixed.

- A change from version 1.4.21 to 1.5.3 would indicate that new features
  were introduced in a backwards-compatible way, and some bugs were fixed.

- A change from version 1.4.21 to 2.0.2 would indicate that breaking changes
  have been introduced, and that old code would probably have to be updated
  before it can be used with the new version

Then it would be possible to refer to a major version and always use the 
newest version of the library, e.g.

  https://example.com/lib-1.js

This could be equivalent (by server-side redirect) to

  https://example.com/lib-1.4.22.js

if the most recent version of the 1.x series is 1.4.22.

This would be similar to how GNU/Linux handles C dynamically linked library 
references.  (A symlink to the newest/preferred version of the library is 
created.)

But not all developers know about or observe semantic versioning, so unless 
the developers of your third-party library do, you have to find a way to 
keep yourself up to date.  One possibility is to subscribe to a newsletter, 
code repository, or social media site of the library, if there is one.

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [next] | [standalone]

#38667

Thomas 'PointedEars' Lahn wrote:

> In theory, there is semantic versioning, with which developers can make
> updates to their code and indicate that the new version only fixes bugs or
> introduces new features, but does not break any existing code:
> 
> - A change from version 1.4.21 to 1.4.22 would indicate that only bugs
> were
>   fixed.
> 
> - A change from version 1.4.21 to 1.5.3 would indicate that new features
>   were introduced in a backwards-compatible way, and some bugs were fixed.
> 
> - A change from version 1.4.21 to 2.0.2 would indicate that breaking
>   changes have been introduced, and that old code would probably have to
>   be updated before it can be used with the new version
> 
> Then it would be possible to refer to a major version and always use the
> newest version of the library, e.g.
> 
>   https://example.com/lib-1.js
> 
> This could be equivalent (by server-side redirect) to
> 
>   https://example.com/lib-1.4.22.js
> 
> if the most recent version of the 1.x series is 1.4.22.

I forgot the reference: <https://semver.org/>

But apparently (from my professional experience) the more common way today 
is to use semantic versioning in your build system, often based on Node.js, 
like Bower or plain npm, build the third-party library together with your 
code, and then refer to the minified (and potentially source-mapped) version 
of that:

<https://docs.npmjs.com/about-semantic-versioning>

-- 
PointedEars
FAQ: <http://PointedEars.de/faq> | <http://PointedEars.de/es-matrix>
<https://github.com/PointedEars> | <http://PointedEars.de/wsvn/>
Twitter: @PointedEars2 | Please do not cc me./Bitte keine Kopien per E-Mail.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.javascript

csiph-web