ਹਰ ਡਿਵੈਲਪਮੈਂਟ ਟੀਮ ਦੀ ਅਜਿਹੀ ਹੀ ਇੱਕ ਕਹਾਣੀ ਹੁੰਦੀ ਹੈ। ਇੱਕ ਪੁੱਲ ਰਿਕੁਐਸਟ (pull request) ਅੱਧੇ ਦਿਨ ਲਈ ਖੁੱਲ੍ਹੀ ਰਹਿੰਦੀ ਹੈ। ਇਸ ਲਈ ਨਹੀਂ ਕਿ ਲੌਜਿਕ (logic) ਖਰਾਬ ਹੈ ਜਾਂ API ਕੰਟਰੈਕਟ ਬਦਲ ਗਿਆ ਹੈ, ਸਗੋਂ ਇਸ ਲਈ ਕਿਉਂਕਿ ਦੋ ਰਿਵਿਊਅਰ ਇਸ ਗੱਲ 'ਤੇ ਅਸਹਿਮਤ ਹਨ ਕਿ ਆਬਜੈਕਟ ਲਿਟਰਲਜ਼ (object literals) ਵਿੱਚ ਟ੍ਰੇਲਿੰਗ ਕਾਮੇ (trailing commas) ਹੋਣੇ ਚਾਹੀਦੇ ਹਨ ਜਾਂ ਨਹੀਂ। ਇਹ ਚਰਚਾ ਵਧਦੀ ਜਾਂਦੀ ਹੈ। ਕੋਈ ਸਟਾਈਲ ਗਾਈਡ (style guide) ਦਾ ਲਿੰਕ ਪੋਸਟ ਕਰਦਾ ਹੈ। ਕੋਈ ਹੋਰ ਵੱਖਰੇ ਗਾਈਡ ਨਾਲ ਜਵਾਬ ਦਿੰਦਾ ਹੈ। ਜਦੋਂ ਤੱਕ ਕੋਡ ਮਰਜ (merge) ਹੁੰਦਾ ਹੈ, ਸ਼ਾਮਲ ਸਾਰੇ ਲੋਕ ਉਨ੍ਹਾਂ ਫੀਚਰਾਂ ਦਾ ਸੰਦਰਭ (context) ਭੁੱਲ ਚੁੱਕੇ ਹੁੰਦੇ ਹਨ ਜਿਨ੍ਹਾਂ 'ਤੇ ਉਹ ਅਸਲ ਵਿੱਚ ਕੰਮ ਕਰ ਰਹੇ ਸਨ।

ਇਹ ਲੜਾਈਆਂ ਮਹਿੰਗੀਆਂ ਪੈਂਦੀਆਂ ਹਨ। ਇਹ ਸੀਨੀਅਰ ਇੰਜੀਨੀਅਰਾਂ ਦੇ ਕਈ ਘੰਟਿਆਂ ਦਾ ਸਮਾਂ ਬਰਬਾਦ ਕਰਦੀਆਂ ਹਨ, ਸਾਥੀਆਂ ਵਿਚਕਾਰ ਨਕਾਰਾਤਮਕਤਾ ਪੈਦਾ ਕਰਦੀਆਂ ਹਨ, ਅਤੇ ਜੂਨੀਅਰ ਡਿਵੈਲਪਰਾਂ ਨੂੰ ਇਹ ਮੰਨਣ ਲਈ ਪ੍ਰੇਰਿਤ ਕਰਦੀਆਂ ਹਨ ਕਿ ਸੌਫਟਵੇਅਰ ਇੰਜੀਨੀਅਰਿੰਗ ਜ਼ਿਆਦਾਤਰ ਸੈਮੀਕੋਲਨ (semicolons) 'ਤੇ ਬਹਿਸ ਜਿੱਤਣ ਬਾਰੇ ਹੈ। ਸਭ ਤੋਂ ਮਾੜੀ ਗੱਲ? ਪ੍ਰੋਡਕਟ ਨੂੰ ਇਸ ਨਾਲ ਕੋਈ ਫਰਕ ਨਹੀਂ ਪੈਂਦਾ। ਤੁਹਾਡੇ ਯੂਜ਼ਰਾਂ ਨੂੰ ਕਦੇ ਵੀ ਸਪੇਸ (space) ਅਤੇ ਟੈਬ (tab) ਦੇ ਫਰਕ ਦਾ ਪਤਾ ਨਹੀਂ ਲੱਗੇਗਾ। ਉਹ ਉਸ ਬੱਗ (bug) ਨੂੰ ਜ਼ਰੂਰ ਦੇਖਣਗੇ ਜਿਸ ਨੂੰ ਤੁਸੀਂ ਠੀਕ ਨਹੀਂ ਕੀਤਾ ਕਿਉਂਕਿ ਤੁਸੀਂ ਕੋਟੇਸ਼ਨ ਮਾਰਕਸ (quote marks) 'ਤੇ ਬਹਿਸ ਕਰਨ ਵਿੱਚ ਰੁੱਝੇ ਹੋਏ ਸਨ।

ਇਕਸਾਰਤਾ (Consistency) ਮਾਇਨੇ ਰੱਖਦੀ ਹੈ। ਇੱਕ ਕੋਡਬੇਸ (codebase) ਜੋ ਅਜਿਹਾ ਲੱਗਦਾ ਹੈ ਜਿਵੇਂ ਕਿ ਕਿਸੇ ਇੱਕ ਵਿਅਕਤੀ ਦੁਆਰਾ ਲਿਖਿਆ ਗਿਆ ਹੋਵੇ, ਉਸ ਨੂੰ ਪੜ੍ਹਨਾ, ਰਿਵਿਊ ਕਰਨਾ ਅਤੇ ਡੀਬੱਗ (debug) ਕਰਨਾ ਆਸਾਨ ਹੁੰਦਾ ਹੈ। ਗਲਤੀ ਇਸ ਨੂੰ ਹੱਥ ਨਾਲ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨ ਵਿੱਚ ਹੈ।

ਬੋਰਿੰਗ ਕੰਮਾਂ ਨੂੰ ਆਟੋਮੇਟ ਕਰੋ

ਇਸ ਦਾ ਹੱਲ ਸਿੱਧਾ ਹੈ। ਫਾਰਮੈਟਿੰਗ ਤੋਂ ਮਨੁੱਖੀ ਫੈਸਲੇ ਲੈਣ ਦੀ ਪ੍ਰਕਿਰਿਆ ਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਹਟਾ ਦਿਓ। ਇਸ ਨੂੰ ਅਜਿਹੇ ਟੂਲਜ਼ (tools) ਨੂੰ ਸੌਂਪ ਦਿਓ ਜਿਨ੍ਹਾਂ ਦਾ ਕੋਈ ਅਹੰਕਾਰ ਨਹੀਂ ਹੈ ਅਤੇ ਜੋ ਥੱਕਦੇ ਨਹੀਂ ਹਨ।

ਤਿੰਨ ਟੂਲ ਇਸ ਨੂੰ ਬੜੀ ਸਫਾਈ ਨਾਲ ਸੰਭਾਲਦੇ ਹਨ।

Prettier ਤੁਹਾਡੇ ਕੋਡ ਨੂੰ ਲੈਂਦਾ ਹੈ ਅਤੇ ਇਸ ਨੂੰ ਆਪਣੇ ਆਪ ਰੀਫਾਰਮੈਟ (reformat) ਕਰ ਦਿੰਦਾ ਹੈ। ਇਹ ਇਜਾਜ਼ਤ ਨਹੀਂ ਮੰਗਦਾ। ਤੁਸੀਂ ਲਾਈਨ ਦੀ ਲੰਬਾਈ, ਕੋਟ ਸਟਾਈਲ, ਜਾਂ ਲੰਬੇ ਫੰਕਸ਼ਨ ਸਿਗਨੇਚਰ (function signature) ਨੂੰ ਲਾਈਨਾਂ ਵਿੱਚ ਕਿਵੇਂ ਤੋੜਨਾ ਹੈ, ਇਸ ਬਾਰੇ ਸੋਚਣਾ ਬੰਦ ਕਰ ਦਿੰਦੇ ਹੋ। ਤੁਸੀਂ ਫਾਈਲ ਸੇਵ ਕਰਦੇ ਹੋ। Prettier ਇਸ ਨੂੰ ਇਕਸਾਰ ਬਣਾ ਦਿੰਦਾ ਹੈ।

ESLint ਉਨ੍ਹਾਂ ਸਮੱਸਿਆਵਾਂ ਨੂੰ ਸੰਭਾਲਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ Prettier ਨਹੀਂ ਛੂਹੇਗਾ। ਇਹ ਅਣਵਰਤੇ ਵੇਰੀਏਬਲਜ਼ (unused variables), ਅਸਮਰੱਥ ਕੋਡ (unreachable code), React hooks ਵਿੱਚ ਗਲਤ ਡਿਪੈਂਡੈਂਸੀਜ਼ (missing dependencies), ਅਤੇ ਅਜਿਹੇ ਪੈਟਰਨਾਂ ਨੂੰ ਫੜਦਾ ਹੈ ਜੋ ਇਤਿਹਾਸਕ ਤੌਰ 'ਤੇ ਬੱਗਾਂ ਦਾ ਕਾਰਨ ਬਣਦੇ ਹਨ। ਜਦੋਂ ਸਹੀ ਤਰ੍ਹਾਂ ਕੌਂਫਿਗਰ ਕੀਤਾ ਜਾਂਦਾ ਹੈ, ਤਾਂ ਇਹ ਫਾਰਮੈਟਿੰਗ ਤੋਂ ਦੂਰ ਰਹਿੰਦਾ ਹੈ ਅਤੇ ਅਸਲ ਕੋਡ ਦੀ ਗੁਣਵੱਤਾ (code quality) 'ਤੇ ਧਿਆਨ ਕੇਂਦਰਿਤ ਕਰਦਾ ਹੈ।

Husky ਇੱਕ pre-commit hook ਇੰਸਟਾਲ ਕਰਦਾ ਹੈ ਜੋ ਆਟੋਮੇਟਡ ਚੈਕ ਪਾਸ ਹੋਣ ਤੱਕ ਕਿਸੇ ਵੀ ਚੀਜ਼ ਨੂੰ ਤੁਹਾਡੇ ਰੈਪੋਜ਼ਟਰੀ (repository) ਵਿੱਚ ਜਾਣ ਤੋਂ ਰੋਕਦਾ ਹੈ। ਇਹ ਤੁਹਾਡੇ Git ਪਾਈਪਲਾਈਨ ਨੂੰ ਸੁਝਾਵਾਂ ਦੇ ਡੱਬੇ ਦੀ ਬਜਾਏ ਇੱਕ ਗੇਟਕੀਪਰ (gatekeeper) ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ।

ਮਿਲ ਕੇ ਇਹ ਇੱਕ ਮਜ਼ਬੂਤ ਲੂਪ (loop) ਬਣਾਉਂਦੇ ਹਨ। ਤੁਸੀਂ ਸਥਾਨਕ ਤੌਰ 'ਤੇ (locally) ਕੋਡ ਜਿਵੇਂ ਚਾਹੋ ਲਿਖੋ। ਜਦੋਂ ਤੁਸੀਂ ਕਮਿਟ (commit) ਕਰਦੇ ਹੋ, ਤਾਂ ਟੂਲਸ ਇਸ ਨੂੰ ਸਾਫ਼ ਅਤੇ ਚੈੱਕ ਕਰਦੇ ਹਨ। ਉਸ ਤੋਂ ਬਾਅਦ ਹੀ ਕੋਡ ਤੁਹਾਡੀ ਮਸ਼ੀਨ ਤੋਂ ਬਾਹਰ ਜਾਂਦਾ ਹੈ।

ਇਹ ਖਾਸ ਸਟੈਕ (stack) ਕਿਉਂ ਕੰਮ ਕਰਦਾ ਹੈ

ਤੁਸੀਂ ESLint ਨਿਯਮਾਂ ਨੂੰ ਹੱਥ ਨਾਲ ਟਿਊਨ ਕਰਨ ਵਿੱਚ ਹਫ਼ਤੇ ਬਿਤਾ ਸਕਦੇ ਹੋ। ਉਸ ਇੱਛਾ ਦਾ ਵਿਰੋਧ ਕਰੋ। ਇੱਥੇ ਉਦੇਸ਼ ਸਟਾਈਲ 'ਤੇ ਬਹਿਸ ਨੂੰ ਰੋਕਣਾ ਹੈ, ਨਾ ਕਿ ਸਟਾਈਲ ਗਾਈਡ ਕਿਊਰੇਟਰ ਵਜੋਂ ਇੱਕ ਨਵੀਂ ਫੁੱਲ-ਟਾਈਮ ਨੌਕਰੀ ਬਣਾਉਣਾ।

Prettier ਜਾਣਬੁੱਝ ਕੇ 'opinionated' ਰੱਖਿਆ ਗਿਆ ਹੈ। ਇਹ ਸੀਮਤ ਕੌਂਫਿਗਰੇਸ਼ਨ ਵਿਕਲਪ ਪੇਸ਼ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਹਰ ਵਿਕਲਪ ਇੱਕ ਭਵਿੱਖ ਦੀ ਬਹਿਸ ਬਣ ਸਕਦਾ ਹੈ। ਡਿਫੌਲਟ ਸੈਟਿੰਗਾਂ ਸਹੀ ਹਨ। ਕੁਝ ਛੋਟੇ ਬਦਲਾਅ (overrides) ਚੁਣੋ, ਉਹਨਾਂ ਨੂੰ ਇੱਕ ਵਾਰ ਲਿਖੋ, ਅਤੇ ਅੱਗੇ ਵਧੋ।

ESLint, ਜੇਕਰ ਇਸ ਨੂੰ ਆਪਣੇ ਆਪ 'ਤੇ ਛੱਡ ਦਿੱਤਾ ਜਾਵੇ, ਤਾਂ ਇਹ ਕੋਡ ਦੀ ਗੁਣਵੱਤਾ ਅਤੇ ਫਾਰਮੈਟਿੰਗ ਨਿਯਮਾਂ ਜਿਵੇਂ ਕਿ ਸੈਮੀਕੋਲਨ ਦੀ ਵਰਤੋਂ ਅਤੇ ਇੰਡੈਂਟ ਸਾਈਜ਼ (indent size) ਦੋਵਾਂ ਨੂੰ ਲਾਗੂ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰੇਗਾ। ਇਹ Prettier ਨਾਲ ਰਗੜ (friction) ਪੈਦਾ ਕਰਦਾ ਹੈ ਕਿਉਂਕਿ ਦੋਵੇਂ ਟੂਲ ਇੱਕੋ ਅੱਖਰਾਂ ਨੂੰ ਐਡਿਟ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਨਗੇ। eslint-config-prettier ਪੈਕੇਜ ਇਸ ਨੂੰ ਉਹਨਾਂ ਸਾਰੇ ESLint ਨਿਯਮਾਂ ਨੂੰ ਡਿਸੇਬਲ ਕਰਕੇ ਹੱਲ ਕਰਦਾ ਹੈ ਜੋ Prettier ਨਾਲ ਟਕਰਾਉਂਦੇ ਹਨ। ਕੰਮਾਂ ਦਾ ਇਹ ਵੰਡਾਅ ਬਹੁਤ ਮਹੱਤਵਪੂਰਨ ਹੈ। Prettier ਸੁੰਦਰਤਾ (cosmetics) ਸੰਭਾਲਦਾ ਹੈ। ESLint ਲੌਜਿਕ (logic) ਸੰਭਾਲਦਾ ਹੈ।

ਸਿਰਫ਼ continuous integration ਵਿੱਚ ਚੈੱਕ ਚਲਾਉਣਾ ਬਹੁਤ ਦੇਰ ਹੋਣਾ ਹੈ। ਜਦੋਂ ਤੱਕ CI ਫੇਲ ਹੁੰਦਾ ਹੈ, ਤੁਸੀਂ ਪਹਿਲਾਂ ਹੀ ਗੰਦਾ ਕੋਡ ਕਮਿਟ ਕਰ ਚੁੱਕੇ ਹੁੰਦੇ ਹੋ, ਦੂਜੇ ਕੰਮ ਵੱਲ ਵਧ ਚੁੱਕੇ ਹੁੰਦੇ ਹੋ, ਅਤੇ ਸ਼ਾਇਦ ਇੱਕ ਪੁੱਲ ਰਿਕੁਐਸਟ ਖੋਲ੍ਹ ਚੁੱਕੇ ਹੁੰਦੇ ਹੋ। ਇਸ ਨੂੰ ਠੀਕ ਕਰਨ ਲਈ ਇੱਕ ਹੋਰ ਕਮਿਟ, ਇੱਕ ਹੋਰ ਪੁਸ਼ (push), ਅਤੇ ਇੱਕ ਹੋਰ ਇੰਤਜ਼ਾਰ ਦੇ ਚੱਕਰ ਦੀ ਲੋੜ ਹੁੰਦੀ ਹੈ। Husky ਉਸ ਫੀਡਬੈਕ ਲੂਪ ਨੂੰ ਸੈਕਿੰਡਾਂ ਵਿੱਚ ਬਦਲ ਦਿੰਦਾ ਹੈ। Lint-staged ਇਸ ਨੂੰ ਤੇਜ਼ ਬਣਾਉਂਦਾ ਹੈ ਕਿਉਂਕਿ ਇਹ ਹਰ ਕਮਿਟ 'ਤੇ ਪੂਰੀ ਰੈਪੋਜ਼ਟਰੀ ਨੂੰ ਸਕੈਨ ਕਰਨ ਦੀ ਬਜਾਏ ਸਿਰਫ਼ ਉਹਨਾਂ ਫਾਈਲਾਂ 'ਤੇ ਟੂਲ ਚਲਾਉਂਦਾ ਹੈ ਜਿਨ੍ਹਾਂ ਨੂੰ ਤੁਸੀਂ ਅਸਲ ਵਿੱਚ ਬਦਲਿਆ ਹੈ।

ਇਸ ਨੂੰ ਸਟੈਪ-ਬਾਈ-ਸਟੈਪ ਸੈੱਟ ਕਰਨਾ

ਹੇਠਾਂ ਦਿੱਤਾ ਗਿਆ ਸੈੱਟਅੱਪ ਇੱਕ ਆਧੁਨਿਕ JavaScript ਜਾਂ React ਪ੍ਰੋਜੈਕਟ ਲਈ ਹੈ, ਪਰ ਇਸ ਪੈਟਰਨ ਨੂੰ ਥੋੜ੍ਹੇ ਜਿਹੇ ਬਦਲਾਅ ਨਾਲ TypeScript, Vue, ਜਾਂ Node 'ਤੇ ਵੀ ਲਾਗੂ ਕੀਤਾ ਜਾ ਸਕਦਾ ਹੈ। ਹਰੇਕ ਸਟੈਪ ਨੂੰ ਆਪਣੇ ਪ੍ਰੋਜੈਕਟ ਰੂਟ (root) ਤੋਂ ਚਲਾਓ।

ਸਭ ਤੋਂ ਪਹਿਲਾਂ ਸਭ ਕੁਝ dev dependencies ਵਜੋਂ ਇੰਸਟਾਲ ਕਰਕੇ ਸ਼ੁਰੂ ਕਰੋ:

npm install -D prettier eslint husky lint-staged eslint-config-prettier