next - 2.10.0-next.X

[vegarringdal]

Figured I could have a thread on what will be and is in next version

fuse-box-typechecker@next

Gulp removed (next.1)

its using fusebox 2.9.0 to make own dist

runSilentSync() (next.4)

Returns object, and does not print any errors to console.
if no check have been preformed it returns undefined

let checkerSync = TypeHelper({
        tsConfig: './tsconfig.json',
        basePath: './',
        tsLint: './tslint.json',
        name: 'returnResultObj'
    });
    const resultObj = checkerSync.runSilentSync();
    console.log(resultObj);

result without errors

one with 2 simple errors

This will display the default paths to settings and name..

runSilentPromise() (next 4)

// same as above, just own thread with promise

var TypeHelper = require('./dist/commonjs/index.js').TypeHelper

let checkerSync = TypeHelper({
    tsConfig: './tsconfig.json',
    basePath: './',
    tsLint: './tslint.json',
    name: 'checkerPromise'
});


checkerSync.runSilentPromise().then((results) => {
    console.log(results)
})

checkerWatch.runWatch('./src', callback) (next.6)

added option for callback

• returns 'edit' on removed file and changed
• returns 'updated' + errors when done

might get some small edits

skipTsErrors?: number[];// skip ts errors (next.7)

• option to skip tsErrors

[dlannoye]

So I did some digging in the code and I think this would work, but looking at the code I think it might work better to just return the objects you are using in printResults. I am thinking that the results object could be an object with the following interface:

{
   lintErrorMessages?: ITSLintError[];
   tsErrorMessages?: ITSError[];
}

These should be pretty straightforward to serialized compared to the full Diagnostics that typescript returns, but also have enough information for scenarios like mine where I want to re-log the errors to a different log.

What do you think of this interface? If you like it I would be willing to refactor to having this for the Obj versions of the check api.

[vegarringdal]

Yes, but splitting it into types is better i the long run, and give users more option, if they want to combine it then that is easier than splitting up.

interface IResults =
{
    lint: ITSLintError[],
    optionsErrors: ITSError[],
    globalErrors: ITSError[],
    syntacticErrors: ITSError[],
    semanticErrors: ITSError[]
}

What we need is a function that can take this:
https://github.com/fuse-box/fuse-box-typechecker/blob/master/src/checker.ts#L150-L156
And return a object that can be serialized so we can pass pass it between processes. (string)
I would prefer if it was in own file, since I have some other refactoring parts I want to do next week. ( so please dont go refactor crazy in the code due to weird stuff 😄 )

We will need to use the new function 2 places:

• https://github.com/fuse-box/fuse-box-typechecker/blob/master/src/worker.ts#L38
• https://github.com/fuse-box/fuse-box-typechecker/blob/master/src/index.ts#L136

Then its just to run gulp build and test it works :-)

Tasks:

• rebuild process functions to use argument, then use these functions
• add new function to worker.ts#L38
• add new function to index.ts#L136
• create and add interface IResults
• new build and test
• add to 2.10.0-next.X...

Tell me if you start working on any of this, I will start when I have time, but next 5 days I dunno how much time I have, in the weekend I will add it if you havent had time yet

[vegarringdal]

Hmm, see not that my thoughts earlier today during lunch break was done a bit to quickly. refactor the process functions I have to take augments instead of using internals will be a lot faster and cleaner.
I also get to start a little with my cleanup then also, let me have a look at this now

[vegarringdal]

@dlannoye
fuse-box-typechecker@2.10.0-next.3

var path = require('path')

//get typehelper (use built source)
var TypeHelper = require('./dist/commonjs/index.js').TypeHelper

// sync run
let checkerSync = TypeHelper({
    tsConfig: './tsconfig.json',
    basePath: './',
    tsLint: './tslint.json',
    name: 'checkerPromiseAndreturnObj'
});


checkerSync.checkSyncReturnObjPromise().then((results) => {
    console.log(results)
})

you can give it a try
should try and reproduce option and global errors so we could test if they make it fail, but I didnt manage to make them 😂

[dlannoye]

For naming are you stuck on checkSyncReturnObj and checkSyncReturnObjPromise to me something like runSilentSync, runSilentPromise and runSilentAsync would be nice to go with the current runPromise, runSync and runAsync apis and indicate that they don't print the results. Also, if you are interested in a bigger change you could move away form the worker doing the printing and have the run* versions of the api just call the runSilent version and then use the result and doing printing there.

This would keep the worker code simple since it would just always return the result object. We would just need to make sure the result object has a enough that the log printing can be done, which is a pretty good sign that developers who call the silent version would have what they need for their logging.

[vegarringdal]

@dlannoye
Hi renaming to runSilentSync and runSilentPromise sounds like a great idea.
Main reason why Im using the next.x now it to be able to do small changes without bringing breaking change :-)

you could move away form the worker doing the printing

no, need to worker to be able to do printing to console, I usually use this when working on a project using fusebox, on the bundle start I call startTreadAndWait() and then on fusebox complete bundle event I call the useThreadAndTypecheck(). Since its doing all work in thread the dev server wont be halted on every bundle update on saves.

Regarding breaking changes, figured we could make what we have stable, try and test if there is a breaking bug ( do you know how to reproduce ts option errors and global ? ). Then we can release and start a new thread about 3.0.0, here we could rename a lot etc, just need to make sure and make a guide how to upgrade so its easy for people

[vegarringdal]

I can rename the functions later today

[vegarringdal]

@dlannoye
fuse-box-typechecker@2.10.0-next.4 published, now they are called runSilentSync and runSilentPromise

[vegarringdal]

@dlannoye
Did you get a chance to test `?
I really need to figure out how to produce a global and a option errors to make sure it works

[dlannoye]

I haven't got a good chance to test it yet. I did do some digging to see if I could produce a global or an option error, but didn't find anything there yet.

[vegarringdal]

@dlannoye

OK, I'll hold back the release of v2.10.0 until you get a chance to test.
This way we dont miss a silly mistake :-)

I will hopefully managed to start on some better tests, just need to find out how far I want to take v3.0.0

[vegarringdal]

@dlannoye

Gotten chance to try it?
Most important part is that you have not noticed any bugs
Also added option to skip tsErrors due to #53
skipTsErrors?: number[];// skip ts errors

[dlannoye]

I tried fuse-box-typechecker@2.10.0-next.7 against several of my projects and everything looked good for them.

…

On Tue, Jun 19, 2018 at 8:50 AM Vegar Ringdal ***@***.***> wrote: @dlannoye <https://github.com/dlannoye> Gotten chance to try it? Most important part is that you have not noticed any bugs Also added option to skip tsErrors due to #53 <#53> skipTsErrors?: number[];// skip ts errors — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#52 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABUdKFmL0L-R4urCFz_2D4xJ9sPY8qJhks5t-R3EgaJpZM4UYAHT> .

[vegarringdal]

Great, Ill prb release it during the weekend then.

[jpike88]

Looks good to me too

[vegarringdal]

@dlannoye @jpike88

version fuse-box-typechecker@2.10.0 released

https://github.com/fuse-box/fuse-box-typechecker/releases/tag/2.10.0