[Pkg-javascript-devel] [RFS] node-trust-json-document

[Jonas Smedegaard]

[ adding back mailinglist as recipient ]

Quoting Ayoyimika Ajibade (2022-02-12 07:00:54)
> > update webpack command
> As part of the migration to webpack5, some options are no more valid 
> example is the -d or -p option which was previously referred to set 
> the development or production environment respectively, hence the 
> change was the functional effect (e.g needed for webpack5), which will 
> try to make my commit messages more descriptive. Thanks for putting 
> that in.

Ah, it is news to me that webpack5 does not support the short-form 
options.

Related note: I run a few Debian systems - laptops and servers - and on 
all of them I install the package apt-listchanges, which shows package 
changes each time I run "apt update && apt update" - which I do at least 
once per day (yeah, I should maybe talk to a psyciatrist about that).  
By default, apt-listchanges show only entries from NEWS files, but I 
reconfigure it with "dpkg-reconfigre apt-listchanges" to also show 
Changelog entries.  In short, I read (or skim, very quickly) all changes 
for all packages on my systems. I learn a lot from informative changelog 
messages.

I find it an amusing little challenge for myself to express changelog 
messages to be both short and informative.  I am not very good at it - 
for inspiration I can recommend looking at changelog messages (and 
mailinglist posts) by Simon McVittie - e.g. gtk4: 
https://tracker.debian.org/media/packages/g/gtk4/changelog-4.6.0ds1-4

I commonly follow one of these patterns for changelog entries:

  * tedious change done
  * change done, highlighting additions
  * change done, highlighting additions (highlighting omissions)

Here, I would maybe write (exactly as you - I am no saint, or) like 
this:

  * update webpack command, to be forward-compatible with webpack5

It is common to fit most possible (i.e. as close to 72 chars) before 
wrapping a line.  I instead break at natural "pauses" in the text, 
called "semantic newlines": https://sembr.org/


> > Change #2: You update DEP-3 header of a patch
> will make necessary changes to the patch

I suggest to *drop* that patch: It is not necessary, just makes the 
patch one line bigger.


> > fix install in binary packages
> don't know if that is the right word 'fix' but there were lots of 
> errors thrown from dh_missing as files were not properly installed 
> even for autopkgtest to use. Please if i may ask why the need for 
> another binary file i.e 
> libjs-trust-json-document_0.1.4~dfsg-11_all.deb

I didn't check but am pretty sure that if you did not apply the next 
commit to use pkg-js-tools, then dh_missing would be silent.

So what you "fixed" was your own changes, not something in the previous 
package release, and therefore your "fix" does not belong in the 
_changelog_ (it is not an activity log).

Common procedure when building a package is this:

 a) prepare sources
 b) configure upstream build system
 c) do an upstream "build"
 d) do an upstream "install" to debian/tmp
 e) copy files from debian/tmp to debian/$PKG
 f) finalize packaging

Node.js packages often provide no upstream "install" task that fits the 
Debian needs.

This package skipped d) and in e) copies directly from source paths.  
dh_missing should not complain about that.

Your later commit introduces pkg-js-tools to handle d) and e), and 
dh_missing then (correctly) complains that something weird is going on: 
files are copied twice.


> > migrate to pkg-js-tools and autopkgtest to handle test suites
> sure i will revert the change, as i wanted to test with autopkgtest. 
> from my limited knowledge, I switched to pkg-js packaging style. Is 
> there any way I can do that?

Make good sense to improve test coverage.

Yes, it is possible to use autopkgtest without pkg-js.  Not as easy, but 
possible more reliable.

autopkgtest already runs a few superficial tests now, before your 
packaging changes: It is setup in the directory debian/tests/

I guess what you want is to _improve_ autopkgtest, to not only do 
superficial tests but also check upstream testsuite (which is currently 
checked only during build).

Upstream testsuite is not designed to check Debian-installed code. Maybe 
pkg-js magically ensures this, but possibly it accidentally checks 
source code instead, which is less useful.

One example of a package that checks upstream Node.js testsuite and 
ensures that system-installed module gets loaded (not local code) is 
node-lunr: run "apt source node-lunr" and see debian/tests/control

Beware that the upstream testsuite for this package seemingly does *not* 
test webpack-generated code, only uncompressed code - so even though 
including upstream testsuite with autopkgtest _is_ a good improvement to 
the packaging, it will _not_ help tracking if webpack migration works or 
not.

The purpose of webpack is generally to make JavaScript usable in a 
browser, so testing that in principle requires loading the code in a 
browser as well.  test-friendly wrappers for browser JavaScript engines 
exist but are rare in Debian, mainly because compiling a modern web 
browser is a HUUUGE task.

For some simpler Node.js modules, their browser-optimized code can 
instead be tested using a crude emulator of a browser environment.  One 
package that does this is node-domino.

Another even simpler but more reliable test is to only check JavaScript 
syntax without executing the code.  A package to do that is eslint.

Examples of packages doing domino and eslint tests of browser code are 
libjs-bootbox, node-terser, and leaflet.


 - Jonas

-- 
 * Jonas Smedegaard - idealist & Internet-arkitekt
 * Tlf.: +45 40843136  Website: http://dr.jones.dk/

 [x] quote me freely  [ ] ask before reusing  [ ] keep private
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: signature
URL: <http://alioth-lists.debian.net/pipermail/pkg-javascript-devel/attachments/20220212/902e85c5/attachment.sig>